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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
