One of Gentoo's packaged patches for libxml2-2.9.10 cause it to segfault on exit for at least some users/consumers, such as dev-ruby/nokogiri. Gentoo's libxml2-2.9.10 includes some post-release-tarball patches from upstream PRs, including https://github.com/GNOME/libxml2/commit/9fa3200cb366c726f7c8ef234282603bb9e8816d which is included as 0034-Call-xmlCleanupParser-on-ELF-destruction.patch in the patchset tarball at https://dev.gentoo.org/~sam/distfiles/ With that patch included, some things segfault on exit. The easiest reproducer I have right now is: $ equery l ruby libxml2 nokogiri * Searching for ruby ... [IP-] [ ] dev-lang/ruby-2.6.6-r2:2.6 * Searching for libxml2 ... [I-O] [ ] dev-libs/libxml2-2.9.10:2 * Searching for nokogiri ... [I-O] [ ] dev-ruby/nokogiri-1.10.10:0 $ cat ruby-libxml2-tester.rb #!/usr/bin/ruby require 'nokogiri' $ ./ruby-libxml2-tester.rb [BUG] Segmentation fault at 0x00000000000004c8 ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux] -- Machine register context ------------------------------------------------ [snip] 7f84e6363000-7f84e64cc000 r--s 00000000 07:04 89135682 /usr/lib64/libxml2.so.2.9.10 [snip] This is actually known upstream, and there's a patch to fix the bug introduced by the patch that Gentoo picked up: https://gitlab.gnome.org/GNOME/libxml2/-/issues/153 https://gitlab.gnome.org/GNOME/libxml2/-/commit/956534e02ef280795a187c16f6ac04e107f23c5d I'll make a PR to add that patch (but the Right Thing might be for it to be added to the bundle as 0062-...patch).
Thanks for this, and even better with the bug references and commits. I'd ask for a traceback but it's probably not needed here given this upstream. Give me a bit of time to look into it, should not be too long.
Oh cool, thanks. Actually I still have a gdb backtrace in scrollback (when I started writing the b.g.o ticket, I had not yet tied it to a known issue upstream; left out these details when it turned out to be a known issue): (gdb) bt #0 0x00007f7b5a282f41 in raise () from /lib64/libc.so.6 #1 0x00007f7b5a26c53d in abort () from /lib64/libc.so.6 #2 0x00007f7b5a43dc37 in rb_bug_context.cold () from /usr/lib64/libruby26.so.2.6 #3 0x00007f7b5a58b952 in sigsegv () from /usr/lib64/libruby26.so.2.6 #4 <signal handler called> #5 0x00007f7b5a4d20dd in ruby_sized_xfree.part () from /usr/lib64/libruby26.so.2.6 #6 0x00007f7b57d3b886 in xmlCleanupCharEncodingHandlers () from /usr/lib64/libxml2.so.2 #7 0x00007f7b57d44939 in xmlCleanupParser__internal_alias.part.0 () from /usr/lib64/libxml2.so.2 #8 0x00007f7b5a754714 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #9 0x00007f7b5a2858d3 in __run_exit_handlers () from /lib64/libc.so.6 #10 0x00007f7b5a285a8c in exit () from /lib64/libc.so.6 #11 0x00007f7b5a26dd22 in __libc_start_main () from /lib64/libc.so.6 #12 0x0000556f47e6115a in _start () (gdb) quit I said I'd make a PR, but since you are looking into this I'll skip that - it's literally just adding that other upstream commit, and if you're likely to bundle into the patch.tar.xz, then I can't do that easily in a PR anyway.
I had been holding off on new versions of nokogiri because they required libxml2 2.9.10 and libxslt 1.1.34. Unfortunately I'm still seeing a segfault when running the tests, and it is the same with both 1.10.4 and 1.10.10. Backtrace: -- C level backtrace information ------------------------------------------- /usr/lib64/libruby25.so.2.5(rb_vm_bugreport+0x50a) [0x7f3ac6886c2a] /usr/lib64/libruby25.so.2.5(0x87849) [0x7f3ac6742849] /usr/lib64/libruby25.so.2.5(0x156302) [0x7f3ac6811302] /lib64/libc.so.6(0x7f3ac653a6a0) [0x7f3ac653a6a0] /usr/lib64/libruby25.so.2.5(ruby_xfree+0x17) [0x7f3ac675ca27] /usr/lib64/libxml2.so.2(xmlCleanupCharEncodingHandlers+0x96) [0x7f3ac5a7f646] /usr/lib64/libxml2.so.2(0x7f3ac5a7bc31) [0x7f3ac5a7bc31] /lib64/ld-linux-x86-64.so.2(0x7f3ac69f03e3) [0x7f3ac69f03e3] /lib64/libc.so.6(0x7f3ac653ccf7) [0x7f3ac653ccf7] /lib64/libc.so.6(0x3aeaa) [0x7f3ac653ceaa] /lib64/libc.so.6(__libc_start_main+0xf2) [0x7f3ac6525e12] /usr/bin/ruby25(_start+0x2a) [0x563b10ec111a] ./main.c:44 This looks like the same issue given that xmlCleanupCharEncodingHandlers is involved here as well. In any case I've just added 1.10.10 since this is not a regression and we will have a nokogiri version that is meant to work with the newer versions of libxml2 and libxslt.
*** Bug 736214 has been marked as a duplicate of this bug. ***
*** Bug 735666 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc0c637a699f51f9736527c162675b52548207c0 commit dc0c637a699f51f9736527c162675b52548207c0 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-08-16 04:23:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-08-16 04:23:15 +0000 dev-libs/libxml2: add upstream patch for consumers Within our patchset (which included various upstream memory correctness fixes), we included a patch (0034-Call-xmlCleanupParser-on-ELF-destruction.patch) which has caused crashes in some applications e.g. nokogiri because they use a custom free handler. We apply upstream's patch for this issue (check-for-custom-free-function-in-global-destructor.patch). We will likely give this a small amount of time in ~arch, then move the stable keywords from 2.9.10 forward, as this is a minor change and affects the current stable for most arches. Bug: https://bugs.gentoo.org/710748 Bug: https://bugs.gentoo.org/737024 Package-Manager: Portage-3.0.2, Repoman-2.3.23 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/libxml2/Manifest | 1 + dev-libs/libxml2/libxml2-2.9.10-r1.ebuild | 224 ++++++++++++++++++++++++++++++ 2 files changed, 225 insertions(+)
I won't close the bug until we make the fixed version stable (in a day or so?). Thanks both for the research & information.
*** Bug 737282 has been marked as a duplicate of this bug. ***
I can confirm that this fixes the nokogiri crashes for me.
(In reply to Hans de Graaff from comment #9) > I can confirm that this fixes the nokogiri crashes for me. Brilliant. If there's no open bugs, the plan is to move the stable keywords forward before midnight to get into the snapshot for tomorrow.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=542bf48302386a611ce63693f42114162f3d86a7 commit 542bf48302386a611ce63693f42114162f3d86a7 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-08-16 22:51:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-08-16 22:51:13 +0000 dev-libs/libxml2: move forward stable keywords This contains a minor fix and we want to get it into today's snapshot. This was suggested in the bug and on IRC with no objections. Closes: https://bugs.gentoo.org/737024 Package-Manager: Portage-3.0.2, Repoman-2.3.23 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/libxml2/libxml2-2.9.10-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
