dlsym() may return an undefined symbol

Cédric Hombourger chombourger at nexwave-solutions.com
Fri Jan 12 13:10:00 UTC 2007


Hello Jocke, thanks for your quick response and apologies for the HTML post that I did. Yes I am more than aware that 0.9.27 is rather old but we unfortunately have to integrate our S/W component loader and runtime into a Linux-based solution provided by a thirdparty (who delivers to us binaries of the linux kernel, uclibc 0.9.27, and of their software stack). We will push for an upgrade to 0.9.28... 

I have reproduced this behaviour with a SVN checkout of uclibc from yesterday. Unfortunately, if I turn on traces then I get a segv (that I will investigate). You will find attached the test program that I used on mipsel-linux-uclibc and below are the traces that I got with LD_DEBUG=all defined. Note that the test program works just fine on mipsel/glibc 2.3.2 (dlsym() returns the same pointer for both calls) while on uclibc, the pointer returned by the second dlsym() is a pointer to .MIPS.stubs resolving a completely different symbol. 

Again thank you for your response, and please let me know if there is something else you need.

Regards,
Cedric Hombourger
NexWave Solutions (www.nexwave-solutions.com)


---
Trace dump after running export DEBUG=all; ./a.out

_dl_get_ready_to_run:630:       file='libdl.so.0';  needed by './a.out'
_dl_load_shared_library:222:    find library='libdl.so.0'; searching
_dl_load_shared_library:298:    searching ldso dir='/lib'
_dl_load_elf_shared_library:629: 
        file='/lib/libdl.so.0';  generating link map
_dl_load_elf_shared_library:630:                dynamic: 0x2aaf012c  base: 0x2aaf0000
_dl_load_elf_shared_library:632:                  entry: 0x2aaf08c0  phdr: 0x2aaf0034  phnum: 0x7

_dl_get_ready_to_run:630:       file='libgcc_s.so.1';  needed by './a.out'
_dl_load_shared_library:222:    find library='libgcc_s.so.1'; searching
_dl_load_shared_library:298:    searching ldso dir='/lib'
_dl_load_elf_shared_library:629: 
        file='/lib/libgcc_s.so.1';  generating link map
_dl_load_elf_shared_library:630:                dynamic: 0x2ab340cc  base: 0x2ab34000
_dl_load_elf_shared_library:632:                  entry: 0x2ab357a0  phdr: 0x2ab34034  phnum: 0x4

_dl_get_ready_to_run:630:       file='libc.so.0';  needed by './a.out'
_dl_load_shared_library:222:    find library='libc.so.0'; searching
_dl_load_shared_library:298:    searching ldso dir='/lib'
_dl_load_elf_shared_library:629: 
        file='/lib/libc.so.0';  generating link map
_dl_load_elf_shared_library:630:                dynamic: 0x2ab8010c  base: 0x2ab80000
_dl_load_elf_shared_library:632:                  entry: 0x2ab8b810  phdr: 0x2ab80034  phnum: 0x6

_dl_get_ready_to_run:630:       file='libc.so.0';  needed by './a.out'
_dl_load_shared_library:222:    find library='libc.so.0'; searching
_dl_load_shared_library:298:    searching ldso dir='/lib'
_dl_get_ready_to_run:630:       file='libc.so.0';  needed by './a.out'
_dl_load_shared_library:222:    find library='libc.so.0'; searching
_dl_load_shared_library:298:    searching ldso dir='/lib'

INIT/FINI order and dependencies:
lib: /lib/libdl.so.0 has deps:
 /lib/libc.so.0 
lib: /lib/libgcc_s.so.1 has deps:
 /lib/libc.so.0 
lib: /lib/libc.so.0 has deps:

_dl_perform_mips_global_got_relocations for './a.out'
_dl_perform_mips_global_got_relocations for '/lib/libdl.so.0'
_dl_perform_mips_global_got_relocations for '/lib/libgcc_s.so.1'
_dl_perform_mips_global_got_relocations for '/lib/libc.so.0'
_dl_fixup:654: relocation processing: /lib/libc.so.0

        Segmentation fault (core dumped)

________________________________

From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se] 
Sent: Friday, January 12, 2007 12:06 AM
To: Cédric Hombourger; uclibc at uclibc.org
Subject: RE: dlsym() may return an undefined symbol


Please don't post non plain text emails.
 
.27 is rather old and much has happened since then in ld.so.
 
your "fix" is broken. Can you repeat this with .28/or SVN ? If so, enable SUPPORT_LD_DEBUG and
run your test app. with LD_DEBUG=all defined 
 
Have you verified that this works as you expect on a glibc based system?
 
 Jocke
 



________________________________

	From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On Behalf Of Cedric Hombourger
	Sent: den 11 januari 2007 23:15
	To: uclibc at uclibc.org
	Subject: dlsym() may return an undefined symbol
	
	

	Hello there,
	
	With a program similar to the one below, we have observed that dlsym of uclibc 0.9.27 may return the wrong function pointer:
	
	librt = dlopen ("librt.so", RTLD_LAZY);
	libc  = dlopen ("libc.so", RTLD_LAZY);
	
	malloc1 = dlsym (libc, "malloc");
	res1 = malloc1 (16); // this one is ok, malloc() is called
	
	malloc2 = dlsym (librt, "malloc");
	res2 = malloc2 (16); // Ouch the stub for malloc from librt.so / section .MIPS.stubs is returned!
	
	After tracing _dl_find_hash, I noticed the following test which I don't understand:
	
	if (type_class & (sym->st_shndx == SHN_UNDEF)) continue;
	
	I did not understand the meaning of the type_class parameter and why it should be non-zero for undefined symbols to be ignored (and BTW dlsym() calls _dl_find_hash with a zero type_class value).
	
	Changing the suspect line to:
	
	if ((sym->st_shndx == SHN_UNDEF)) continue;
	
	seem to have fixed the issue but frankly, I am not sure whether this does not cause other issues.
	
	I fairly new to uclibc, any help/comment would be highly appreciated.
	
	Note: it seems that this piece of code wasn't changed in the latest snapshots - right?
	
	Regards,
	Cedric Hombourger
	NexWave Solutions (www.nexwave-solutions.com)
	
	

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlsym-issue-check.c
Type: application/octet-stream
Size: 728 bytes
Desc: dlsym-issue-check.c
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20070112/30bd48de/attachment-0002.obj 


More information about the uClibc mailing list