Control: severity -1 important Control: retitle -1 libxml2: fails to read some gzip compressed files Control: tags -1 - fixed-upstream Control: found -1 2.9.0+dfsg1-4
Le mercredi 19 décembre 2012 à 03:39 +0100, Vincent Lefevre a écrit : > I've done tests with gdb, and the problem occurs at > > xmlParseDocument( ctxt->data.saxParserCtxt ); > > in src/backend/xml/sixtp.c line 709 (sixtp_parse_file_common). > It comes from a known bug in libxml2, discussed here: > > https://bugzilla.redhat.com/show_bug.cgi?id=877567 > > It is fixed upstream. I could check with xmllint on the compressed > file that this is the same bug: > > $ xmllint test.gnucash > test.gnucash:222630: parser error : expected '>' > </trn:d [...] > No such problem with the uncompressed file. If I truncate the > uncompressed file at </trn:d line 222630 like above, I get the > same problem. I don't think this issue is release critical. The risk of data loss was located on the GnuCash side, and is now fixed. This bug seems to affect only specific gzip-compressed XML files. Moreover, there is an easy workaround, which is to decompress then recompress the gzip'd XML file with the gunzip/gzip commands. Also, the bug is not fixed upstream, because the patch attached to the Fedora bug report has not been applied upstream (the patch looks very ugly, but Fedora apparently applied it anyways because for some reason it was a blocker for their own internal workflow). Using the test file given in the Fedora bug report, I verified that the bug is still present in libxml2 2.9.0+dfsg1-4. -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594
signature.asc
Description: This is a digitally signed message part
