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 Jaeger wrote:
> 
> >>>>> 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.

I did that. First i compiled against the orignal SuSE provided glibc,
then i
i tried glibc-2.1.2 - same result.
I am going to build a very small test program to see what happens then.

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

-- 
stud. rer. nat. Andreas Schultz - student of computer science

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