segmentation fault in the jvm

Wed Mar 23 09:31:26 PDT 2011

Thanks for your reply.

What is the recommended way to debug "legitimate" seg faults when 
invoking the JVM?

I am creating a JVM using the invocation API, and getting a seg fault, 
probably because of a memory problem in our C code.  It says "Command 
terminated by signal 11" when running without gdb, but no stack trace.

After I got that, I ran the program in gdb to try to debug it, and 
eventually isolated the problem to the test case I sent out before.  But 
it seems like that's not related to the original problem...?

Thanks,

Stefanie

On 03/23/2011 11:32 AM, Christian Thalinger wrote:
> [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-dev at 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
>
>