This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: shared library results in wrong function version


>>>>> Andreas Schultz writes:

 > Hi,
 > I noticed this problem with linuxthreads, but i may apply to other
 > functions to.

 > libpthreads has two version for a number of functions, e.g:

 > nm /usr/lib/libpthread.so | grep sem_post
 > 00008480 t __new_sem_post
 > 000099a0 t __old_sem_post
 > 00008480 T sem_post@@GLIBC_2.1
 > 000099a0 T sem_post@GLIBC_2.0  

 > A program linked against this lib should now use the @@GLIBC_2.1
 > version, resulting in
 > a call to __new_sem_post. GDB however shows that __old_sem_post is
 > called - resulting in
 > a segfault.

 > The static linked version of the program works flawless.

 > enviroment:

 > SuSE 6.2 upgraded with:

 > Linux 2.3.25
 > glibc-2.1.2
 > gcc 2.95.2
 > binutils 2.9.5.0.16
  
 > I had the same problem with glibc 2.1.1

 > The program uses a rather large shared library, which has ca. 10k
 > symbols

 > ldd micotest
 >         libmico2.3.0.so => /home/aschultz/mico/orb/libmico2.3.0.so
 > (0x40014000)
 >         libpthread.so.0 => /lib/libpthread.so.0 (0x404be000)
 >         librt.so.1 => /lib/librt.so.1 (0x404d1000)
 >         libdl.so.2 => /lib/libdl.so.2 (0x404d5000)
 >         libm.so.6 => /lib/libm.so.6 (0x404d9000)
 >         libc.so.6 => /lib/libc.so.6 (0x404f6000)
 >         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)  

 > ls -l micotest
 > -rwxr-xr-x   1 aschultz users     2358053 Nov 15 20:25 micotest

 > ls -l /home/aschultz/mico/orb/libmico2.3.0.so
 > -r-xr-xr-x   1 aschultz users     9637906 Nov 15 18:49
 > /home/aschultz/mico/orb/libmico2.3.0.so 


 > The error is get:
 > Program received signal SIGSEGV, Segmentation fault.
 > sem_restart_list (waiting=0x0) at oldsemaphore.c:191
 > 191         waiting = waiting->p_nextwaiting;
 > Current language:  auto; currently c
 > (gdb) bt
 > #0  sem_restart_list (waiting=0x0) at oldsemaphore.c:191
 > #1  0x404c79fe in __old_sem_post (sem=0x806800c) at oldsemaphore.c:157
 > #2  0x40280e32 in MICO::msg_queue::put_msg (this=0x8068000, nextOP_id=3,
 >     msg=0x40846ff4) at ../include/mico/os-thread/pthreads.h:107
 > #3  0x4027f185 in MICO::thread_pool_manager::put_msg (this=0x8067f40,
 >     nextOP_id=3, msg=0x40846ff4) at mt_manager.cc:89
 > #4  0x402797ca in MICO::Operation::send_msg (this=0x40840fe8,
 > nextOP_id=3,
 >     msg=0x40846ff4) at Operation.cc:92

 > *It should never call a function from oldsemaphore  !!!!* right ????

Wrong.  If libmico has been compiled against an older glibc, it uses
the older implementation.  You've got to differentiate between
run-time linking and compile time linking.  At compile time the
binding of sem_post is decided.  I advise to recompile the mico libs.


Andreas
-- 
 Andreas Jaeger   
  SuSE Labs aj@suse.de	
   private aj@arthur.rhein-neckar.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]