segmentation fault in the jvm

[Stefanie Tellex]

To partially answer my own question, what I'm doing now based on 
Christian's information is pressing "c" in gdb to tell it to ignore the 
seg fault and keep going.

Eventually it gets to my seg fault, which has a non-jvm stack trace...

Stefanie

On 03/23/2011 12:31 PM, Stefanie Tellex wrote:
> 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
>>
>>
>