Crash 3.4.0 - libxml2.2.dylib: xmlMallocZero +48

[BPerlakiH]

[BPerlakiH]

@kelson42 I had a deeper look at this.
We have a dependency called Fuzi, which is a swift wrapper around libxml2.
It is linking the system provided version of libxml2 at build time.

There main issue is that it won't fail properly if initialised with invalid xml/html content data, there's already a long standing issue on that on Fuzi's side.

I implemented the proposed changes for that, and linked my version of Fuzi to the project, but it's still not 100%, as it is not failing properly under all conditions. Additional to that some issues have been already fixed in the underlying libxml2 as well. comparing my local version (2.09) and the latest libxml2 version 2.13.2.

We have a couple of options here, bearing in mind that only 2 devices crashed:

• A) try to enforce the latest version of libxml2 by manually adding it and linking it, and use a fork of Fuzi for that
• B) switch Fuzi and libxml2 to something else (quality of 3rd party packages might vary, so there's no guarantee it will be an actual improvement)
• C) we use the html parsing in 2 places, the search and the bookmark. For the bookmarks there's already a proposition to remove the html parsing. We can do the same for search. The difference is:

Search results with default html parsing option (first sentence):

Search results with html parsing disabled:

We can be more subtle here, either:

• C1) disable this functionality in the next release, so the html parsing won't be used, if we find a better replacement for it we can re-enable it.
• C2) Remove html parsing completely, including the feature flag and settings of this.
• D) Postpone this fix

[kelson42]

@BPerlakiH Thank you for the analysis. Please make a PR to remove for bookmarks. For search results, the libkiwix has a function to provide the HTML snippet, so I don't understand why this is not used!

[BPerlakiH]

Thank you @kelson42.
Here's the updated PR to remove parsing from bookmarks: #830.
As part of the issue then, I will look into how we could use the html snippet from libkiwix, instead of this parsing.

[BPerlakiH]

Ok, I figured this out. We have 4 options to display some extra field as part of the search results.
It can be:

• Disabled
• First paragraph
• First sentence
• Matches

First paragraph and First sentence is using the html parser to get some more info from the content.
Matches, is actually using what you were referring to @kelson42 , which is the matching snippet from libzim.
If we turn on "matches", the results may vary, as we have 2 types of search results, one where the title is matching, one is matching the indexed content:

As you can see, where the title matches there's no additional info, whereas where the content is matching there's an extra field.

This is is to be compared with the default behaviour (First Paragraph):