segmentation fault
Dan Cojocar
dan.cojocar at gmail.com
Thu Jul 1 12:43:59 PDT 2010
Hello Coleen,
Using -Xss1m and -XX:StackShadowPages=20, I managed to get
the StackOverflowError and fix the problem.
Thank you,
Dan
On Wed, Jun 30, 2010 at 8:03 PM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:
>
> It looks like a stack overflow error then. Try increasing your stack size
> with -Xss and/or use the parameter -XX:StackShadowPages=n where n > default
> (3 or 4) so that there is enough stack to report the StackOverflowError.
>
> Thanks,
> Coleen
>
>
> On 06/30/10 12:14, Dan Cojocar wrote:
>
> Hello Coleen,
> Thank you for your suggestion. I posted here because I suspected that this
> is related to the hotspot.
> I don't receive and output crash, I get only the seg fault message in logs.
> And if I configure the system to dump cores, I will get a core dump image.
> That is why I didn't filed a bug report. Should I enable/check something to
> trigger an output crash report?
> Using -Xcheck:jni as you suggested I received a backtrace like the one
> bellow.
> What should I do more to investigate this?
> Regards,
> Dan
>
> (gdb) bt
> #0 0x00002aac6f84a4b2 in MemRegion::end (this=Cannot access memory at
> address 0x42413ff8
> ) at /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/memory/memRegion.hpp:57
> #1 0x00002aac6f84a4f6 in MemRegion::contains (this=0xb2fdad8,
> addr=0xfad9ef48) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/memory/memRegion.hpp:70
> #2 0x00002aac6f84ae49 in CollectedHeap::is_in_reserved (this=0xb2fdac8,
> p=0xfad9ef48) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/gc_interface/collectedHeap.hpp:201
> #3 0x00002aac6f85942b in oopDesc::is_oop (this=0xfad9ef48,
> ignore_mark_word=false) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/oop.inline.hpp:534
> #4 0x00002aac6fb7271d in HandleArea::allocate_handle (this=0xc41dce8,
> obj=0xfad9ef48) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/runtime/handles.cpp:32
> #5 0x00002aac6f98c3fd in Handle::Handle (this=0x42414150, obj=0xfad9ef48)
> at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/runtime/handles.inline.hpp:32
> #6 0x00002aac6f98c427 in constantPoolHandle::constantPoolHandle
> (this=0x42414150, obj=0xfad9ef48) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/runtime/handles.hpp:188
> #7 0x00002aac6faf8b0c in fieldDescriptor::initialize (this=0x42414240,
> k=0xfad9fce0, index=0) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/runtime/fieldDescriptor.cpp:68
> #8 0x00002aac6fb9ee19 in instanceKlass::find_local_field_from_offset
> (this=0xfad9fcf0, offset=12, is_static=false, fd=0x42414240)
> at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:817
> #9 0x00002aac6fb9ee92 in instanceKlass::find_field_from_offset
> (this=0xfad9fcf0, offset=12, is_static=false, fd=0x42414240)
> at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:828
> #10 0x00002aac6fc26511 in checkInstanceFieldID (thr=0xba70800,
> fid=0x3ca7747a33, obj=0x42424380, ftype=10) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jniCheck.cpp:236
> #11 0x00002aac6fc27fe6 in checked_jni_GetIntField (env=0xba709e8,
> obj=0x42424380, fieldID=0x3ca7747a33) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jniCheck.cpp:1024
> #12 0x00002aaab35d9c52 in Java_java_net_SocketInputStream_socketRead0
> (env=0xba709e8, this=0x42424378, fdObj=0x42424380, data=0x42424388, off=0,
> len=4, timeout=0)
> at ../../../src/solaris/native/java/net/SocketInputStream.c:75
> #13 0x00002aaaab5b6dc7 in ?? ()
> #14 0x0000000000000000 in ?? ()
>
>
>
>
> On Wed, Jun 30, 2010 at 5:06 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>
>
> This email is for primarily for discussion about the Hotspot code base and
> not really for support. If you think this is a bug in hotspot you can file
> a bug (as directed in the output of the crash).
>
> From the stack it looks like there's some bug in the native code. Try
> running -Xcheck:jni and see if that helps diagnose your problem.
>
> Coleen
>
>
> On 06/22/10 04:02, Dan Cojocar wrote:
>
>
>
> Hello,
> I'm running resin app server to process jms messages from an activemq
> queue
> and for last couple of days the jvm keeps crashing. I'm using CentOS
> release
> 5.4 (Final) and in dmesg logs I get something like:
> java[16538]: segfault at 0000000044d45ff8 rip 00002aab1b8964f8 rsp
> 0000000044d46000 error 6
> I get the segfault also running with: jdk1.6.0_16 or jdk1.6.0_20.
> Compiled openjdk-7-ea-src-b98-17_jun_2010 with debug and using gdb I see
> the
> following backtraces:
>
> 1. Core was generated by `/home/dcojocar/jdk/build/-debug/bin/java
> -Dresin.watchdog=16600 -Djava.util.log'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00002b56ca667f40 in markOopDesc::value (this=Cannot access memory at
> address 0x442daff8
> ) at /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/markOop.hpp:102
> 102 uintptr_t value() const { return (uintptr_t) this; }
> (gdb) bt
> #0 0x00002b56ca667f40 in markOopDesc::value (this=Cannot access memory at
> address 0x442daff8
> ) at /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/markOop.hpp:102
> #1 0x00002b56ca676c89 in markOopDesc::hash (this=0x3867ac1901) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/markOop.hpp:346
> #2 0x00002b56ca676cb1 in markOopDesc::has_no_hash (this=0x3867ac1901) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/markOop.hpp:350
> #3 0x00002b56ca84b3aa in oopDesc::identity_hash (this=0x9ad9fbf0) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/oops/oop.inline.hpp:662
> #4 0x00002b56ca982414 in jfieldIDWorkaround::klass_hash_ok (k=0x9ad9fbf0,
> id=0x70cf583233) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jni.cpp:167
> #5 0x00002b56ca982506 in jfieldIDWorkaround::verify_instance_jfieldID
> (k=0x9ad9fbf0, id=0x70cf583233) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jni.cpp:180
> #6 0x00002b56ca988913 in jfieldIDWorkaround::from_instance_jfieldID
> (k=0x9ad9fbf0, id=0x70cf583233) at
>
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/runtime/jfieldIDWorkaround.hpp:130
> #7 0x00002b56ca985249 in jni_GetIntField (env=0x145fb9e8, obj=0x442eb270,
> fieldID=0x70cf583233) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jni.cpp:1703
> #8 0x00002aaab282bc52 in Java_java_net_SocketInputStream_socketRead0
> (env=0x145fb9e8, this=0x442eb268, fdObj=0x442eb270, data=0x442eb278,
> off=0,
> len=4, timeout=0)
> at ../../../src/solaris/native/java/net/SocketInputStream.c:75
> #9 0x00002aaaab599a27 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> 2. Core was generated by `/home/dcojocar/jdk/build/-debug/bin/java
> -Dresin.watchdog=16600 -Djava.util.log'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00002b80d0a8d366 in StackObj::StackObj (this=0x42b02180) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/memory/allocation.hpp:97
> 97 class StackObj ALLOCATION_SUPER_CLASS_SPEC {
> (gdb) bt
> #0 0x00002b80d0a8d366 in StackObj::StackObj (this=0x42b02180) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/memory/allocation.hpp:97
> #1 0x00002b80d0eacd3e in JNITraceWrapper::JNITraceWrapper
> (this=0x42b02180,
> format=0x2b80d1327434 "GetIntField") at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jni.cpp:214
> #2 0x00002b80d0eaa218 in jni_GetIntField (env=0x194729e8, obj=0x42b12240,
> fieldID=0x70cf583233) at
> /home/dcojocar/jdk/openjdk/hotspot/src/share/vm/prims/jni.cpp:1703
> #3 0x00002aaaaf1a3c52 in Java_java_net_SocketInputStream_socketRead0
> (env=0x194729e8, this=0x42b12238, fdObj=0x42b12240, data=0x42b12248,
> off=0,
> len=111, timeout=0)
> at ../../../src/solaris/native/java/net/SocketInputStream.c:75
> #4 0x00002aaaab5c9fa7 in ?? ()
> #5 0x0000000000000000 in ?? ()
>
> Please advice what should I do next.
> Regards,
> Dan
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100701/412b3b40/attachment.html
More information about the hotspot-dev
mailing list