On 1 April 2012 08:55, PHilip RUshik <[email protected]> wrote: > On Sat, Mar 31, 2012 at 11:07 PM, PHilip RUshik <[email protected]> wrote: > >> >> >> On Fri, Mar 30, 2012 at 10:44 PM, PHilip RUshik <[email protected]> wrote: >> >>> >>> >>> On Fri, Mar 30, 2012 at 9:12 PM, Filippo ARCIDIACONO < >>> [email protected]> wrote: >>> >>>> >>>> >>>> > -----Original Message----- >>>> > From: [email protected] [mailto:[email protected]] On >>>> > Behalf Of PHilip RUshik >>>> > Sent: Friday, March 30, 2012 1:03 PM >>>> > To: [email protected] >>>> > 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 >>>> > [email protected] >>>> > 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 > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
