Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...
Java Forum / Virtual Machine / July 2004

Tip: Looking for answers? Try searching our database.

JVM Segfaults

Thread view: 
Enable EMail AlertsStart New Thread
Joe Cohen - 13 Jul 2004 21:06 GMT
Hi,

   I am trying to track a JVM crash.  I've removed all JNI code from
my application, so it seems to be triggered by standard java code.
When I start my java server application in gdb I start to see lots of
SIGSEV's though (I also see a SIGTRAP and lots of SIG32's, but I don't
think these indicate a problem).  Unfortunately, when I try to cut
down the code that causes the SIGSEV to a small reproduceable case, it
disappears.

   I am running on Linux RedHat 7.2 with JDK/JRE 1.4.2_04 (although
when I run the app under gdb in Windows (cygwin), I get similar
results).

   When I don't run in gdb the problem doesn't manifest itself until
the app crashes (which is tough to reproduce -- unlike the very
dependable segfaults).  It seems odd that the JVM traps segfaults
though -- doesn't a segfault indicate a critical (i.e. unrecoverable)
application error!?

   I've posted the stack trace from the first segfault when the app
starts up below.  It seems particularly odd because it looks like
strcpy is calling some JNI function!?  Please help.

Program received signal SIGSEGV, Segmentation fault.
0x42dd5ef6 in ?? ()
(gdb) where
#0  0x42dd5ef6 in ?? ()
#1  0x42dce104 in ?? ()
#2  0x4043d9f4 in JavaCalls::call_helper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#3  0x40522b9d in os::os_exception_wrapper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#4  0x4043dc46 in JavaCalls::call ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#5  0x40446447 in jni_invoke_nonstatic ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#6  0x4044967e in jni_CallObjectMethod ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#7  0x40801b46 in JNU_GetStringPlatformChars ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libjava.so
#8  0x40805e8f in Java_java_io_UnixFileSystem_canonicalize0 ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libjava.so
#9  0x42dd6f2f in ?? ()
#10 0x42dd0d14 in ?? ()
#11 0x42dd0d14 in ?? ()
#12 0x42dd0d14 in ?? ()
#13 0x42dce104 in ?? ()
#14 0x4043d9f4 in JavaCalls::call_helper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#15 0x40522b9d in os::os_exception_wrapper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#16 0x4043dc46 in JavaCalls::call ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#17 0x4048ffd0 in JVM_DoPrivileged ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#18 0x407f9165 in Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2
() from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libjava.so
#19 0x42dd6f2f in ?? ()
#20 0x42dd0d14 in ?? ()
#21 0x42dd0deb in ?? ()
#22 0x42dd0deb in ?? ()
#23 0x42dd0d14 in ?? ()
#24 0x42dd0d14 in ?? ()
#25 0x42dd0d14 in ?? ()
#26 0x42dd0d14 in ?? ()
#27 0x42dd0d14 in ?? ()
#28 0x42dd0d14 in ?? ()
#29 0x42dd0d14 in ?? ()
#30 0x42dce104 in ?? ()
#31 0x4043d9f4 in JavaCalls::call_helper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#32 0x40522b9d in os::os_exception_wrapper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#33 0x4043dc46 in JavaCalls::call ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#34 0x4048ffd0 in JVM_DoPrivileged ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#35 0x407f920f in Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2
()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libjava.so
#36 0x42dd6f2f in ?? ()
#37 0x42dd0d14 in ?? ()
#38 0x42dd0d14 in ?? ()
#39 0x42dd0d14 in ?? ()
#40 0x42dd0d14 in ?? ()
#41 0x42dd0d14 in ?? ()
#42 0x42dce104 in ?? ()
#43 0x4043d9f4 in JavaCalls::call_helper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#44 0x40522b9d in os::os_exception_wrapper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#45 0x4043dc46 in JavaCalls::call ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#46 0x4043d5d0 in JavaCalls::call_special ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#47 0x40582fcf in SystemDictionary::load_instance_class ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#48 0x40582a0c in SystemDictionary::resolve_instance_class_or_null ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#49 0x40586a32 in SystemDictionary::resolve_or_null ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#50 0x40581c34 in SystemDictionary::resolve_or_fail ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#51 0x4049e39f in find_class_from_class_loader ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#52 0x4048da5e in JVM_FindClassFromClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#53 0x407e1412 in last_use ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#54 0x407e1471 in last_use ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#55 0x407e1da4 in last_use ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#56 0x407e9197 in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#57 0x407e8cbd in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#58 0x407e88e7 in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#59 0x407e58f7 in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#60 0x407e44e6 in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#61 0x407e2868 in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#62 0x407e2348 in VerifyClass ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libverify.so
#63 0x407ff3cd in VerifyClassCodes ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libjava.so
#64 0x405bacb7 in Verifier::verify_byte_codes ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#65 0x4042038c in instanceKlass::link_class_impl ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#66 0x40420545 in instanceKlass::initialize_impl ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#67 0x40425f8f in instanceKlass::initialize ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#68 0x4049e3e8 in find_class_from_class_loader ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#69 0x4048d6b0 in JVM_FindClassFromClassLoader ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#70 0x407f997e in Java_java_lang_Class_forName0 ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/libjava.so
#71 0x42dd6f2f in ?? ()
#72 0x42dd0d14 in ?? ()
#73 0x42dd0d14 in ?? ()
#74 0x42dd0d14 in ?? ()
#75 0x42dce104 in ?? ()
#76 0x4043d9f4 in JavaCalls::call_helper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#77 0x40522b9d in os::os_exception_wrapper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#78 0x4043dc46 in JavaCalls::call ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#79 0x4042154f in instanceKlass::call_class_initializer_impl ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#80 0x40425c7c in instanceKlass::call_class_initializer ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#81 0x404207ab in instanceKlass::initialize_impl ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#82 0x40425f8f in instanceKlass::initialize ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#83 0x404dffb2 in LinkResolver::resolve_field ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#84 0x404e1885 in LinkResolver::resolve_field ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#85 0x404302b8 in InterpreterRuntime::resolve_get_put ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#86 0x42dde079 in ?? ()
#87 0x42dd0deb in ?? ()
#88 0x42dd0d14 in ?? ()
#89 0x42dd0deb in ?? ()
#90 0x42dd0deb in ?? ()
#91 0x42dd0deb in ?? ()
#92 0x42dce104 in ?? ()
#93 0x4043d9f4 in JavaCalls::call_helper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#94 0x40522b9d in os::os_exception_wrapper ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#95 0x4043dc46 in JavaCalls::call ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#96 0x40445ebc in jni_invoke_static ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#97 0x40454a2d in jni_CallStaticVoidMethod ()
  from /usr/java/j2sdk1.4.2_04/jre/lib/i386/server/libjvm.so
#98 0x0804964d in strcpy ()
#99 0x4004f5d7 in __libc_start_main () from /lib/libc.so.6
(gdb)
Reply to this Message
Chris Uppal - 14 Jul 2004 09:16 GMT
> When I start my java server application in gdb I start to see lots of
> SIGSEV's
> [...]
>  It seems odd that the JVM traps segfaults
> though -- doesn't a segfault indicate a critical (i.e. unrecoverable)
> application error!?

I don't know about JDK/Linux JVM, but I think that it's quite a common
technique for clever GC implementations to use guard pages to avoid explicit
bounds checks.  It's ages since I did any *nix programming but I think that
guard pages are implemented by moving the relevant addresses out of the
process's mapped address space so that any attempt to access them will trigger
a SEGV fault, which the GC implementation traps and recovers from.  Is it
possible that you are seeing this happening ?

Sorry this is so speculative, but I haven't seen any more helpful replies yet.

   -- chris
Reply to this Message
Artur Biesiadowski - 14 Jul 2004 18:35 GMT
> I don't know about JDK/Linux JVM, but I think that it's quite a common
> technique for clever GC implementations to use guard pages to avoid explicit
> bounds checks.  

Most common case of SIGSEGV catching is null pointer exception handling.
You don't perform any checks for null in generated code, just allow code
to dereference 0 address and then trap SIGSEGV and creating
NullPointerException based on the stack frame.

Using it for GC is less trivial - place where you can possibly use it is
per-thread local allocation area, with protection violation caused by
trying to allocate more area than it is available. I don't know if any
jvm uses this technique - after all, protecting versus it is just one
check on heap top pointer, which has to be accessed anyway.

Artur
Reply to this Message


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage
Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.