[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#723982: dlopen: segfaults right inside call_init



Control: reassign -1 src:eglibc

On Sb, 21 sep 13, 23:07:02, Yann Dirson wrote:
> Source: libc6
> Version: 2.17-92+b1
> Severity: normal
> 
> While updating the tulip package to new upstream version, I get a
> systematic segfault when tulip attempts to load its plugins.
> 
> I would understand that call_init() would call some code inside the
> dlopen'd module and segfault there, but in this case the backtrace
> seems to tell that the segfault is occuring inside libc.
> 
> According to the backtrace reproduced below, the presumably-faulty
> code at dl-init.c:84 is:
> 
>       addrs = (ElfW(Addr) *) (init_array->d_un.d_ptr + l->l_addr);
>       for (j = 0; j < jm; ++j)
> 84:     ((init_t) addrs[j]) (argc, argv, env);
> 
> Looks like either addrs would be bogus, or any the pointers therein,
> and this code does not check either of them, and does not seem to
> provide any simple means of knowing which of those conditions occured
> (and recompiling libc just for this may be seen as a bit like overkill :).
> 
> Even looking at the call_init() code, it is not obvious which code is
> supposed to be run, as dlopen(3) only mentions _init and
> __attribute__((constructor)) as possible hooks, and the code talks
> about DT_INIT_ARRAY.  Looking at the elf sections in the plugin,
> .init_array looks like a good candidate, but is it really necessary to
> read the libc code and infer such things to reach such a conclusion ?
> 
> 
> $ objdump -s -j .init_array /usr/lib/tulip//libogdfvisibility-4.3.0.so
> 
> /usr/lib/tulip//libogdfvisibility-4.3.0.so:     file format elf64-x86-64
> 
> Contents of section .init_array:
>  2102e8 00900000 00000000 e0710000 00000000  .........q......
> 
> I assume this can be an array of 64bit pointers, or relocatable
> addresses in the plugin itself that would have been relocated already
> when used - but I can't find what they would refer to in this .so file.
> 
> 
> Any hint of a simple way to track such a problem ?  Wouldn't it be
> possible to make call_init() more helpful in case of failure ?
> 
> 
> Reading symbols from /usr/bin/tulip...Reading symbols from /usr/lib/debug/.build-id/d0/b7ce81909c9154903346982ab0ba3e52f06725.debug...done.
> done.
> (gdb) r
> Starting program: /usr/bin/tulip
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Fontconfig warning: "/etc/fonts/conf.d/41-arphic-uming.conf", line 16: Having multiple <family> in <alias> isn't supported and may not work as expected
> ...
> Fontconfig warning: "/etc/fonts/conf.d/64-arphic-uming.conf", line 47: Having multiple values in <test> isn't supported and may not work as expected
> No probe DLL specified.
> [New Thread 0x7fffe8dd4700 (LWP 4127)]
> [New Thread 0x7fffe332c700 (LWP 4128)]
> [New Thread 0x7fffe2923700 (LWP 4129)]
> [Thread 0x7fffe332c700 (LWP 4128) exited]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7de99e4 in call_init (env=0x7fffffffdd18, argv=0x7fffffffdd08, argc=1, l=<optimized out>) at dl-init.c:84
> 84      dl-init.c: No such file or directory.
> (gdb) bt
> #0  0x00007ffff7de99e4 in call_init (env=0x7fffffffdd18, argv=0x7fffffffdd08, argc=1, l=<optimized out>) at dl-init.c:84
> #1  call_init (l=<optimized out>, argc=1, argv=0x7fffffffdd08, env=0x7fffffffdd18) at dl-init.c:34
> #2  0x00007ffff7de9aca in _dl_init (main_map=main_map@entry=0x79d410, argc=1, argv=0x7fffffffdd08, env=0x7fffffffdd18) at dl-init.c:133
> #3  0x00007ffff7dedaf9 in dl_open_worker (a=a@entry=0x7fffffffd2d8) at dl-open.c:566
> #4  0x00007ffff7de9826 in _dl_catch_error (objname=objname@entry=0x7fffffffd2c8, errstring=errstring@entry=0x7fffffffd2d0, mallocedp=mallocedp@entry=0x7fffffffd2c7,
>     operate=operate@entry=0x7ffff7ded780 <dl_open_worker>, args=args@entry=0x7fffffffd2d8) at dl-error.c:177
> #5  0x00007ffff7ded329 in _dl_open (file=0x7c92c8 "/usr/lib/tulip//libogdfvisibility-4.3.0.so", mode=-2147483646, caller_dlopen=<optimized out>, nsid=-2, argc=1, argv=0x7fffffffdd08,
>     env=0x7fffffffdd18) at dl-open.c:656
> #6  0x00007ffff1ef6026 in dlopen_doit (a=a@entry=0x7fffffffd4e0) at dlopen.c:66
> #7  0x00007ffff7de9826 in _dl_catch_error (objname=0x6ad9d0, errstring=0x6ad9d8, mallocedp=0x6ad9c8, operate=0x7ffff1ef5fc0 <dlopen_doit>, args=0x7fffffffd4e0) at dl-error.c:177
> #8  0x00007ffff1ef65ec in _dlerror_run (operate=operate@entry=0x7ffff1ef5fc0 <dlopen_doit>, args=args@entry=0x7fffffffd4e0) at dlerror.c:163
> #9  0x00007ffff1ef60c1 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
> #10 0x00007ffff7ad3f36 in tlp::PluginLibraryLoader::loadPluginLibrary (filename=..., loader=loader@entry=0x772db0)
>     at /work/yann/deb/tulip/tulip-git/library/tulip-core/src/PluginLibraryLoader.cpp:120
> #11 0x00007ffff7ad40fd in tlp::PluginLibraryLoader::initPluginDir (this=0x691030, loader=loader@entry=0x772db0)
>     at /work/yann/deb/tulip/tulip-git/library/tulip-core/src/PluginLibraryLoader.cpp:260
> #12 0x00007ffff7ad4be0 in tlp::PluginLibraryLoader::loadPlugins (loader=loader@entry=0x772db0, folder=...) at /work/yann/deb/tulip/tulip-git/library/tulip-core/src/PluginLibraryLoader.cpp:67
> #13 0x00007ffff75cf997 in tlp::initTulipSoftware (loader=loader@entry=0x772db0, removeDiscardedPlugins=removeDiscardedPlugins@entry=true)
>     at /work/yann/deb/tulip/tulip-git/library/tulip-gui/src/TlpQtTools.cpp:208
> #14 0x000000000041d130 in main (argc=1, argv=<optimized out>) at /work/yann/deb/tulip/tulip-git/software/tulip/src/main.cpp:168
> (gdb) f 10
> #10 0x00007ffff7ad3f36 in tlp::PluginLibraryLoader::loadPluginLibrary (filename=..., loader=loader@entry=0x772db0)
>     at /work/yann/deb/tulip/tulip-git/library/tulip-core/src/PluginLibraryLoader.cpp:120
> 120       void *handle = dlopen (filename.c_str() , RTLD_NOW);
> (gdb) call filename.c_str()
> $1 = 0x7c92c8 "/usr/lib/tulip//libogdfvisibility-4.3.0.so"
> (gdb)
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt

Attachment: signature.asc
Description: Digital signature


Reply to: