Segfault in libdl-0.9.33.so

PHilip RUshik prushik at gmail.com
Sun Apr 1 06:55:31 UTC 2012


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


More information about the uClibc mailing list