dlsym SEGV in certain cases
Kars de Jong
jongk@cs.utwente.nl
Thu Apr 1 00:00:00 GMT 1999
>Submitter-Id: net
>Originator: Kars de Jong
>Organization:
------------------------------------------------------------------------------
Kars de Jong Signaalkamp rules the waves! Turrican@Discworld
--------======]**-----| jongk@cs.utwente.nl |-----**[======---------
>
>Confidential: no
>Synopsis: dlsym(RTLD_NEXT, <symbol>) gives a SEGV when called from a shared library.
>Severity: critical
>Priority: high
>Category: libc
>Class: sw-bug
>Release: libc-2.0.112
>Environment:
Host type: m68k-unknown-linux-gnu
System: Linux rincewind 2.1.131 #19 Sun Jan 17 22:41:47 CET 1999 m68k unknown
Architecture: m68k
CPU: 68060
Addons: crypt linuxthreads
Build CFLAGS: -O2 -m68020-60
Build CC: egcs
Compiler version: egcs-2.91.60 19981201 (egcs-1.1.1 release)
Kernel headers: 2.2.0-pre7
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: no
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
>Description:
I'm working on the JDK, and when using green_threads this gives a SEGV when
looking up a symbol with dlsym(RTLD_NEXT, ...) from a shared library.
This doesn't happen with the glibc 2.0 that comes with RedHat 5.2.
A backtrace from gdb:
#0 0xc00ce3c4 in dlsym (handle=0xffffffff, name=0xc002d838 "__sigprocmask") at dlsym.c:87
87 return (_dlerror_run (dlsym_doit, &args)
#1 0xc002676c in green_sigprocmask (how=2, set=0x0, oset=0x8000531a)
at ../../../../../src/linux/hpi/green_threads/src/signals.c:618
618 func = (fn_t *)dlsym(RTLD_NEXT, "__sigprocmask");
#2 0xc00279e8 in threadBootstrapMD (tidP=0xeffff97c, lockP=0xc00c9030, nb=122)
at ../../../../../src/linux/hpi/green_threads/src/threads_md.c:127
#3 0xc002c3da in sysThreadBootstrap (tidP=0xeffff97c, lockP=0xc00c9030, nb=122)
at ../../../../../src/linux/hpi/src/system_md.c:93
#4 0xc00b7028 in InitializeJavaVM (args=0xeffff9be)
at ../../../../src/share/javavm/runtime/javai.c:715
#5 0xc008e760 in JNI_CreateJavaVM (vm=0xeffffa2c, penv=0xeffffa28, args=0xeffff9be)
at ../../../../src/share/javavm/runtime/jni.c:3266
#6 0x8000177e in InitializeJVM (pvm=0xeffffa2c, penv=0xeffffa28, ifn=0xeffffa04)
at ../../../../../src/share/bin/java.c:467
#7 0x80000ca8 in main (argc=0, argv=0xeffffa48) at ../../../../../src/share/bin/java.c:173
The function green_sigprocmask is in a shared object, libhpi_g.so:
>From To Syms Read Shared Object Library
0xc0013000 0xc00313ea Yes /usr/src/devel/jdk1.2v/build/linux/bin/m68k/green_threads/../../../lib/m68k/green_threads/libhpi_g.so
0xc0032000 0xc00c909c Yes /usr/src/devel/jdk1.2v/build/linux/bin/m68k/green_threads/../../../lib/m68k/classic/libjvm_g.so
0xc00cd000 0xc00d0d68 Yes /lib/libdl.so.2
0xc00d1000 0xc018465c Yes /lib/libc.so.6
0xc0185000 0xc01876c0 Yes /lib/libBrokenLocale.so.1
0xc0188000 0xc019cfac Yes /lib/libnsl.so.1
0xc019d000 0xc01b8c38 Yes /lib/libm.so.6
0xc0000000 0xc001299c Yes /lib/ld.so.1
At the SEGV args looks like this:
$9 = {handle = 0xffffffff, name = 0xc002d838 "__sigprocmask", version = {
name = 0xffffffff <Address 0xffffffff out of bounds>, hash = 4026529440, hidden = -1073572488,
filename = 0xc00310c4 ""}, caller = 3221383020, loadbase = 0, ref = 0x0}
loadbase = 0, which probably means it wasn't found. libhpi_g.so was however linked against
libc, so I suppose it should have found the symbol.
>How-To-Repeat:
See above.
>Fix:
No idea. Is the JDK using RTLD_NEXT in a defined way? Anyway, it shouldn't give a SEGV :)
More information about the Libc-alpha
mailing list