Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11
Helmut Grohne
helmut at subdivi.de
Thu Jun 6 13:18:38 BST 2024
Hi,
I'm chiming in, because this FTBFS puts us in a difficult spot regarding
/usr-move. The FTBFS makes bash bd-uninstallable and as long as bash is
not built, debootstrap will fail for unstable. This only affects armel,
ppc64el and s390x.
On Mon, Jun 03, 2024 at 03:22:28PM +0800, Aron Xu wrote:
> On Sat, Jun 1, 2024 at 2:26 AM gregor herrmann <gregoa at debian.org> wrote:
> > Also, please don't close _this_ bug in the upload; getting the
> > dependency meta-information in order should fix the autopkgtest
> > failures, but the core problem most probably will persist: The test
> > failures on several architectures which makes the package FTBFS:
> > https://buildd.debian.org/status/package.php?p=libxml-libxml-perl
> >
>
> I have removed the Closes from changelog and uploaded libxml2 to
> unstable. Let's see how it goes.
Looks like your upload didn't fix things. Hence, I dug a little into it.
I opted for reproducing on armel. As in all of the buildd failures,
t/13dtd.t failed. After a failed build, one may issue:
perl -Iblib/lib -Iblib/arch t/13dtd.t
Unlike the test suite wrapper, this doesn't fork and thus is
instrumentable. I also note that it does not fail reliably, but about
2/3 of the time (sampled 200 times). My gdb-fu wasn't exactly helping:
#0 0xf7e66bd0 in free () from /lib/arm-linux-gnueabi/libc.so.6
#1 0xf7b9942c in xmlResetError () from /lib/arm-linux-gnueabi/libxml2.so.2
#2 0xf7b9990c in ?? () from /lib/arm-linux-gnueabi/libxml2.so.2
I also rarely saw SIGABRT instead of SIGSEGV combined with glibc
complaining about the pointer passed to free(). With the knowledge that
we are facing memory corruption, we may head back to amd64 where we have
valgrind:
$ valgrind perl -Iblib/lib -Iblib/arch t/13dtd.t
==1303314== Memcheck, a memory error detector
==1303314== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1303314== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==1303314== Command: perl -Iblib/lib -Iblib/arch t/13dtd.t
==1303314==
1..18
ok 1 - Loaded
ok 2 - DTD String read
ok 3 - XML::LibXML::Dtd successful.
ok 4 - DTD String same as new string.
ok 5 - ->parse_string
ok 6 - ->parse_string 2
ok 7 - parse the article.xml file
ok 8 - valid XML file
ok 9 - Validates
ok 10 - ->parse_string 3
==1303314== Conditional jump or move depends on uninitialised value(s)
==1303314== at 0x6877FE1: __xmlRaiseError (error.c:492)
==1303314== by 0x68B8913: xmlErrValidNode (valid.c:152)
==1303314== by 0x68B8913: xmlValidateElementContent.constprop.0 (valid.c:5362)
==1303314== by 0x68BFF48: xmlValidateOneElement (valid.c:6057)
==1303314== by 0x68C0892: xmlValidateElement (valid.c:6288)
==1303314== by 0x68C0892: xmlValidateElement (valid.c:6275)
==1303314== by 0x68C0B19: xmlValidateDtd (valid.c:6546)
==1303314== by 0x67EC0A5: XS_XML__LibXML__Document_is_valid (LibXML.xs:4047)
==1303314== by 0x24828F: ??? (in /usr/bin/perl)
==1303314== by 0x23DDC5: Perl_runops_standard (in /usr/bin/perl)
==1303314== by 0x176E5D: perl_run (in /usr/bin/perl)
==1303314== by 0x14C531: main (in /usr/bin/perl)
==1303314==
==1303314== Conditional jump or move depends on uninitialised value(s)
==1303314== at 0x67FA8D9: XS_XML__LibXML__LibError_context_and_column (LibXML.xs:9284)
==1303314== by 0x24828F: ??? (in /usr/bin/perl)
==1303314== by 0x23DDC5: Perl_runops_standard (in /usr/bin/perl)
==1303314== by 0x16DF60: Perl_call_sv (in /usr/bin/perl)
==1303314== by 0x680BB02: LibXML_struct_error_callback (LibXML.xs:223)
==1303314== by 0x6878284: __xmlRaiseError (error.c:631)
==1303314== by 0x68B8913: xmlErrValidNode (valid.c:152)
==1303314== by 0x68B8913: xmlValidateElementContent.constprop.0 (valid.c:5362)
==1303314== by 0x68BFF48: xmlValidateOneElement (valid.c:6057)
==1303314== by 0x68C0892: xmlValidateElement (valid.c:6288)
==1303314== by 0x68C0892: xmlValidateElement (valid.c:6275)
==1303314== by 0x68C0B19: xmlValidateDtd (valid.c:6546)
==1303314== by 0x67EC0A5: XS_XML__LibXML__Document_is_valid (LibXML.xs:4047)
==1303314== by 0x24828F: ??? (in /usr/bin/perl)
==1303314==
ok 11 - invalid XML
ok 12 - ->validate throws an exception
ok 13 - ->validation returns 1
ok 14 - Threw an exception
ok 15 - Throw an exception 2
ok 16 - Two child nodes
ok 17 - XML::LibXML::Dtd not defined.
ok 18 - XML::LibXML::Dtd->new working correctly
==1303314==
==1303314== HEAP SUMMARY:
==1303314== in use at exit: 10,735,630 bytes in 38,953 blocks
==1303314== total heap usage: 117,760 allocs, 78,807 frees, 23,844,404 bytes allocated
==1303314==
==1303314== LEAK SUMMARY:
==1303314== definitely lost: 23,136 bytes in 33 blocks
==1303314== indirectly lost: 59,036 bytes in 34 blocks
==1303314== possibly lost: 10,544,904 bytes in 38,816 blocks
==1303314== still reachable: 108,554 bytes in 70 blocks
==1303314== of which reachable via heuristic:
==1303314== newarray : 54,032 bytes in 1,649 blocks
==1303314== suppressed: 0 bytes in 0 blocks
==1303314== Rerun with --leak-check=full to see details of leaked memory
==1303314==
==1303314== Use --track-origins=yes to see where uninitialised values come from
==1303314== For lists of detected and suppressed errors, rerun with: -s
==1303314== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)
$
Notably, when I see crashes on armel, they're always after test 10,
which is where we see the use of uninitialized values. Maybe, amd64 is
just a bit luckier with its choice of uninitialized values?
Digging into the source of libxml2 __xmlRaiseError examines a ctxt
pointer, which is a casted aliased of its fourth argument ctx.
xmlErrValidNode receives a xmlValidCtxtPtr ctxt and passes
ctxt->userData as ctx to __xmlRaiseError. This first ctxt argument is
common to a number of xmlValidate* functions and passed from the
LibXML.xs in is_valid as cvp. The is_valid function initializes
cvp->userData to saved_error, which is defined by the
PREINIT_SAVED_ERROR.
It is a surprising that libxml2 interprets the use ctx->userData field
as a xmlParserCtxt*. Looking closer, it only does that when ctx->flags
has XML_VCTXT_USE_PCTXT set. When that bit is unset, xmlErrValid
reliably sets the ctx argument to __xmlRaiseError to NULL. Hence, we may
assume that XML_VCTXT_USE_PCTXT is set. LibXML.xs does not mention
XML_VCTXT_USE_PCTXT though. Reading the libxml source tells that any
place that sets this bit in ctx->flags also sets ctx->userData to
something compatible with that use.
I locally instrumented LibXML.xs's is_valid to show its cvp.flags and
it's uninitialized (and 0 on amd64)!
So let's test the hypothesis.
--- a/LibXML.xs
+++ b/LibXML.xs
@@ -4025,6 +4025,6 @@
CODE:
INIT_ERROR_HANDLER;
+ memset(&cvp, 0, sizeof(cvp));
cvp.userData = saved_error;
cvp.error = (xmlValidityErrorFunc)LibXML_validity_error_ctx;
cvp.warning = (xmlValidityWarningFunc)LibXML_validity_warning_ctx;
And after this change the segfaulting test passes, but I still get other
failures from dh_auto_test.
Is this good enough to go ahead and upload a slightly less FTBFSy
version of libxml-libxml-perl to see more of the remaining failure?
Helmut
More information about the pkg-perl-maintainers
mailing list