[uClibc] dlopen segfault

Mudrony Laszlo mudry at mudry.hu
Tue Aug 24 16:37:38 UTC 2004


I've built and booted an uclibc/busybox based partition with all the
development stuff in it, and started building extra packages inside
this uclibc linux such as cvs, svn, alsa-lib, directfb, etc.

Everitything compiles and works fine, except that some apps crash,
including svn clinet and all alsa clients. I've compiled both 
uclibc-0.9.26 and alsa-lib-1.0.6 with debugging, and gdb
showed me that the crash happens in uclibc's libdl's libdl.c,
line 206.

202 for (tcurr = tpnt; tcurr; tcurr = tcurr->next)
203 {
204   Elf32_Dyn *dpnt;
205   char *lpntstr;
206   for (dpnt = (Elf32_Dyn *) tcurr->dynamic_addr; dpnt->d_tag; dpnt++) {
207   if (dpnt->d_tag == DT_NEEDED) {

So it crashes walking some ELF descriptor lists. It crashes because
tcurr->dynamic contains junk. Seems that apps that_depend_ o some .so 
files do work fine, while apps that try to dlopen the very same
.so file crash on dlopen. uclibc's dlopen tests work fine.

I didn't had the time to trace down how that junk got there, but I guess 
  that's a bug. Howerver I wanted to see if I can work around the 
problem by modifying it into:

205 char *lpntstr;
206 dpnt = (Elf32_Dyn *) tcurr->dynamic_addr
207 if ((void*)dpnt<=(void*)tcurr) continue;
208 for (; dpnt->d_tag; dpnt++) {

(I've also added some debugging printfs too). Of course this is a dirty
hack, but because the junk pointer is around 0x6000 it works. Now it 
crashes at a different dpnt walking location, so I consider this as a 
limited success.

Unfortunately this another location is in uclibc ldso's elf_hash.c, 
function _dl_find_hash. I dont have a line number for it (gdb didn't 
gave it, so I guess there is no debug info in ld.so). Hacking the 
similar walk at the beginning of find_hash() the similar way causes all
sorts of unresolved symbols (like stderr) so this shows how crappy this 
  fix was :)

All my libs are compiled for the VIA c3-2 Nemeiah CPU. Compiling for
i386 didn't help. I've also tried compiling both uclibc and alsa-lib 
from both a buildroot environment under glibc, and from inside the 
uclibc linux, with no difference.

At this point I'm stuck. Anyone with some ideas about where I should 
look? I'm accesible trough irc/icq/msn (and on this list) and looking 
for someone to help debug this stuff out.

Also, should I post such mails into uclibc developers list instead?

Regards, Mudry

More information about the uClibc mailing list