[Bcc'ing jdk7-dev.] On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: > Hi, > > Not sure if this is the right place to report this,
The right list would be: hotspot-...@openjdk.java.net > but I have a Java program that reliably seg faults the JVM when run under > GDB. It doesn't seem to happen (quickly) when I run it without gdb. It > also doesn't seem to happen if I turn off the JIT, although the original seg > fault that triggered this (part of a much larger program) would still happen > with the JIT turned off, although it took longer. > > The program is attached, and the command I am running is this: > > gdb --args $JAVA_HOME/jre/bin/java -classpath . Test > > The java program loops forever. It gets through about 10 iterations and then > seg faults with this backtrace: > > (gdb) bt > #0 0xb4192300 in ?? () > Cannot access memory at address 0x234 What you are seeing is that compiled code uses various signals for different things, like implicit null-pointer checks. It happens when running in GDB because the debugger handles such signals by default. When you run the java command in GDB in compiled mode (-Xcomp) you will see something like: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x1beb70 (LWP 13690)] 0xf4e74fcc in ?? () Ignoring SEGSEGV signals and continuing should run the java command fine: (gdb) handle SIGSEGV noprint Signal Stop Print Pass to program Description SIGSEGV No No Yes Segmentation fault (gdb) c Continuing. Usage: java [-options] class [args...] ... Hope that helps. -- Christian > > > I also wrote a simple JNI program (attached in the tar.gz) that creates the > JVM and calls Test programmatically. When I run it, it seg faults after > about 10 iterations, (sometimes more, sometimes fewer, every once in a while > it will run for quite a long time). > (gdb) bt > #0 0x41171329 in ?? () > #1 0x4107f3bd in ?? () > #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () > from > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () from > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*) () > from > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, > JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () > from > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #6 0x4044b2bb in jni_NewObjectV () from > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #7 0x40471542 in checked_jni_NewObjectV () from > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, > methodID=0x80eb088) > at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 > #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 > #10 0x08048a16 in main () at c/create_jvm.cxx:116 > > > I ran the same program in valgrind and I get lots of errors about call_helper > doing invalid writes: > > ==24756== > ==24756== Invalid write of size 4 > ==24756== at 0x5494416: ??? > ==24756== by 0x548C0F6: ??? > ==24756== by 0x548BD04: ??? > ==24756== by 0x548BE29: ??? > ==24756== by 0x54893BC: ??? > ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) (in > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) (in > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*) (in > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x44B0A0F: JVM_DoPrivileged (in > /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x540E07A: > Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 > (AccessController.c:67) > ==24756== by 0x549571A: ??? > ==24756== by 0x548BE29: ??? > ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) free'd > > > I've reproduced this against 1.7 as well as 1.6 and 1.5. > > There are some bugs that seem to refer to this problem, although they don't > seem to be fixed or to have reproduction instructions. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 > > Any hints would be appreciated. > > Stefanie
