Re: HTML parser sometimes doesn't close script tags in libxml2 2.9.8
Nick Wellnhofer <[email protected]> Wed, 23 Jan 2019 12:55:48 +0100
| Newsgroups | gmane.comp.gnome.lib.xml.general |
|---|---|
| Message-ID | <[email protected]> |
On 23/01/2019 01:47, Tomi Belan wrote: > But even so I still wasn't able to reproduce it in pure C. Could it be > because xmllint reads ctxt->myDoc, and lxml uses SAX2 event handlers > (according to parsertarget.pxi)? AFAICT xmllint's --push and --sax options are > incompatible. ctxt->myDoc is also built via internal SAX2 handlers, so I'm not sure what's going on exactly. > I had more luck with git bisect. Using a dynamically linked build of lxml, and > pointing LD_LIBRARY_PATH to libxml2/.libs/, I successfully found out that the > bug was: > - introduced by > https://github.com/GNOME/libxml2/commit/6e6ae5daa6cd9640c9a83c1070896273e9b30d14 > - fixed(?) by > https://github.com/GNOME/libxml2/commit/7a1bd7f6497ac33a9023d556f6f47a48f01deac0 The first commit was an attempt to fix an (ICU-related?) issue but it turned out to be buggy. It's unfortunate that the commit made it into 2.9.8. https://mail.gnome.org/archives/xml/2018-January/msg00003.html https://bugs.chromium.org/p/chromium/issues/detail?id=820163 > I hope that's meaningful to you, because I have no idea what are those commits > doing and how could it be related to this bug... The commits sound related to > character encoding, but bad.html is plain ASCII... The commit obviously also affected documents that didn't need encoding conversion. I didn't realize that. At least we know that the issue is isolated to 2.9.8. Thanks for your efforts! Nick