Segfault in libdl-0.9.33.so

Carmelo Amoroso carmelo73 at gmail.com
Sun Apr 1 13:20:00 UTC 2012


On 1 April 2012 08:55, PHilip RUshik <prushik at gmail.com> wrote:
> On Sat, Mar 31, 2012 at 11:07 PM, PHilip RUshik <prushik at gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 30, 2012 at 10:44 PM, PHilip RUshik <prushik at gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 30, 2012 at 9:12 PM, Filippo ARCIDIACONO <
>>> filippo.arcidiacono at st.com> wrote:
>>>
>>>>
>>>>
>>>> > -----Original Message-----
>>>> > From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On
>>>> > Behalf Of PHilip RUshik
>>>> > Sent: Friday, March 30, 2012 1:03 PM
>>>> > To: uclibc at uclibc.org
>>>> > Subject: Segfault in libdl-0.9.33.so
>>>> >
>>>> > Both ncurses and SDL crash whenever an application using them crashes.
>>>> > dmesg tells me that sdl related crashes are segfaults in libdl-
>>>> > 0.9.33.so,
>>>> > which is (correct me if I'm wrong) the library for the dynamic loader?
>>>>
>>>> It is the library provide the support to dynamically load shared
>>>> libraries.
>>>>
>>>> > There isn't much more info since I didn't build with debugging
>>>> > libraries.
>>>> > Its strange that this is happening, it worked previously, and I don't
>>>> > think
>>>> > I changed anything in my uclibc config except for adding fenv
>>>> > functions,
>>>> > which shouldn't affect SDL since SDL is only written in C.
>>>> > Everything on my system is dynamically linked, and most things run fine
>>>> > including complex applications such as Xfbdev, and even Abiword. Any
>>>> > ideas
>>>> > about what the problem could be?
>>>>
>>>> With the info you provide is difficult understand where is the problem,
>>>> What I suggest you is to build the uClibc with SUPPORT_LD_DEBUG and
>>>> SUPPORT_LD_DEBUG_EARLY enabled, they could give some useful info.
>>>> Which arch are you using?
>>>>
>>>> > If it would be helpful, I could show you my uclibc config file (or
>>>> > some relevant portion of it).
>>>> >
>>>> >
>>>> > --PHil
>>>> > _______________________________________________
>>>> > uClibc mailing list
>>>> > uClibc at uclibc.org
>>>> > http://lists.busybox.net/mailman/listinfo/uclibc
>>>>
>>>>
>>> I know its not much information, sorry. The arch is x86_64, I know its an
>>> unusual target architecture, sorry about that. It was built with a binutils
>>> 2.22 and GCC 4.5.3 / 4.6.3 / 4.7.0 (all three resulted in the same problem).
>>> I'll add those debug options and rebuild everything. I'm starting the
>>> build now. I'll let you know.
>>>
>>>
>>>
>>> --PHil
>>>
>>
>> I enabled those config options, but the output (for the SDL crash) was
>> exactly the same. However, strangely enough, nano started working. So I'm
>> rebuilding again with even more debugging enabled.
>> For anybody who is interested, my target is x86_64 and I am building with
>> gcc 4.6.3. I replied earlier, but once again I accidentally only sent it to
>> one person instead of the mailing list.
>>
>>
>> --PHil
>>
>
> This is the info that gets printed directly before the segmentation fault:
>
> argc=1 argv=0x7fffd3194398 envp=0x7fffd31943a8
> ELF header=0x7f69d02d9000
> First Dynamic section entry=0x7f69d04e2d90
> Scanning DYNAMIC section
> Done scanning DYNAMIC section
> About to do library loader relocations
> Done relocating ldso; we can now use globals and make function calls!
> _dl_get_ready_to_run:454: Cool, ldso survived making function calls
> _dl_malloc:246: mmapping more memory
> _dl_ldsopath_init:162: Lib Loader: (0xd02d9000) /lib/ld64-uClibc.so.0:
> using path: /lib
> _dl_get_ready_to_run:660: calling mprotect on the application program
> _dl_get_ready_to_run:1042: Loading: (0x7f69d00d5000)
> /usr/lib/libSDL_net-1.2.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfe40000)
> /usr/lib/libSDL-1.2.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfa02000) /usr/lib/libpng14.so.14
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf7f3000)
> /usr/lib/libSDL_mixer-1.2.so.0
> _dl_malloc:246: mmapping more memory
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf5e4000) /lib/libm.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_load_elf_shared_library:758: Found TLS header for /lib/libc.so.0
> _dl_load_elf_shared_library:785: Relocated TLS initial image from 0x26f758
> to 0x7f69cf3cb758 (size = 0x8)
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfe40000)
> /usr/lib/libSDL-1.2.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf5e4000) /lib/libm.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cef57000) /lib/libdl.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69ced54000) /usr/lib/libts-1.0.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69d02d9000) /lib/ld64-uClibc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cef57000) /lib/libdl.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_malloc:246: mmapping more memory
> _dl_get_ready_to_run:1042: Loading: (0x7f69ceb3d000) /usr/lib/libz.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf5e4000) /lib/libm.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfe40000)
> /usr/lib/libSDL-1.2.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf5e4000) /lib/libm.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cef57000) /lib/libdl.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69ced54000) /usr/lib/libts-1.0.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69ce91f000) /usr/lib/libmad.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69d02d9000) /lib/ld64-uClibc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69d02d9000) /lib/ld64-uClibc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cef57000) /lib/libdl.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1
> _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
> _dl_get_ready_to_run:1183: Calling init_tls()!
> _dl_malloc:246: mmapping more memory
> _dl_malloc:246: mmapping more memory
> _dl_get_ready_to_run:1285: Beginning relocation fixups
> _dl_get_ready_to_run:1315: Calling _dl_allocate_tls_init()!
> transfering control to application @ 0x410b30
> _dl_update_slotinfo:702: Updating slotinfo for module 1
>
>
> None of it seems helpful at all... dmesg reports exactly the same useless
> info, even when I built everything with debugging symbols...
>
>
> --PHil

Build uClibc with debug syms and you apps as well and use gdb to do a
real debug session.

Carmelo
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc


More information about the uClibc mailing list