[uclibc-ng-devel] segfault in dlclose() when lots of shared objects are dlopened - the story continues

Bernd Kuhls bernd.kuhls at t-online.de
Tue Jul 18 21:17:55 CEST 2017


Hi,

investigating a segfault

(gdb) bt full
#0  0x00007fffec28dd90 in __deregister_frame_info () from /lib/
libgcc_s.so.1
No symbol table info available.
#1  0x00007fffebf8af66 in __do_global_dtors_aux () from /usr/lib/
libgcrypt.so.20

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:

2012:
http://lists.uclibc.org/pipermail/uclibc/2012-October/047059.html

2014:
http://lists.busybox.net/pipermail/uclibc/2014-December/048737.html

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
64
Segmentation fault

Please note that using Apache without mod_php works fine, php-cgi itself 
also works fine.

In 2014 Anthony suggested to revert
https://git.busybox.net/uClibc/commit/ldso?
h=0.9.33&id=9b42da7d0558884e2a3cc9a8674ccfc752369610

which still solves the Apache/mod_php segfault today.

Uclibc-1.0.19 includes all commits from 2016-09-26 and older in
https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/log/ldso/libdl

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.

Regards, Bernd



More information about the devel mailing list