[uclibc-ng-devel] segfault in dlclose() when lots of shared objects are dlopened - the story continues
wbx at uclibc-ng.org
Thu Jul 20 20:16:12 CEST 2017
Bernd Kuhls wrote,
> investigating a segfault
> (gdb) bt full
> #0 0x00007fffec28dd90 in __deregister_frame_info () from /lib/
> No symbol table info available.
> #1 0x00007fffebf8af66 in __do_global_dtors_aux () from /usr/lib/
> when starting Apache with mod_php activated on a buildroot-built x86_64-
> system with uclibc-1.0.19 I came across discussions from 2012 & 2014 on
> the uClibc mailinglist:
> Building mod_php without libgcrypt.so, which means disabling
> BR2_PACKAGE_PHP_EXT_XSL, does not fix the problem, the segfault will
> occur in another shared lib.
> Quoting the message from 2014:
> > In my particular case, this meant dlopening and dlclosing some 47
> > shared objects as reported by "LD_DEBUG=1 /usr/bin/gdk-pixbuf-query-
> > loaders ./libpixbufloader-svg.la 2>&1 | grep ^do_dlopen | grep ctors
> > | wc -l"
> My system opens even more shared libs when starting Apache & mod_php:
> # LD_DEBUG=1 /usr/bin/httpd -t 2>&1 | grep ^do_dlopen | grep ctors | wc -l
> Segmentation fault
> Please note that using Apache without mod_php works fine, php-cgi itself
> also works fine.
> In 2014 Anthony suggested to revert
> which still solves the Apache/mod_php segfault today.
> Uclibc-1.0.19 includes all commits from 2016-09-26 and older in
> it therefore includes https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/
> commit/ldso/libdl?id=cc04ab27ba6341f46bbe094478c9af3e3706f411 which
> refers to fix the problem from the 2012 message, but it did not.
Thanks for the detailed investigation.
Indeed reverting the mentioned commit fixes also some long standing
bug I have seen when executing "php -m" to list all modules
installed in a system. (normally the ldap module generated the
segfault in my case)
I reverted the patch, this will be part of the next release.
More information about the devel