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 <[email protected]> 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
