JVM Error
I've seen similar problems - java is very sensitive to each thread beeing 'registered'. My understanding is that attaching the thread will set all the TLDs that are needed, and jk2 is calling the attach method - so I don't know what is wrong here. My bet would be on thread creation - I would add some printf with the TID serving the request ( before attaching the thread ). One thing that may happen in 10 minutes is the thread management code adding or removing threads. Costin Right, something like that. The deepest I can debug is jk2_vm_attach function in jk_vm_default.c module. The function makes a call to JNI's GetEnv method, and if result indicates the thread is not attached, calls AttachCurrentThread. Well, I see Web server create a brand new thread, and GetEnv returns an environment pointer for it... This is obviously wrong and causes a problem later when JK2 attempts to call a static method in Tomcat. I thought GetEnv may be broken somehow and altered the code so Attach always happens. No luck either - this time access violation happens in AttachCurrentThread and stack backtrace looks like this: jk2_vm_attach(env = 0x1cc220, jkvm = 0x224fc0) jni_AttachCurrentThread(0xfe0a0338, 0x580f00, 0x0, 0xfe092000, 0xee171668, 0x0) Thread::initialize_thread_local_storage(0x580f00, 0x6, 0x580f00, 0x0, 0x0, 0x0) ThreadLocalStorage::set_thread(0xfe092000, 0x580f00, 0x580f00, 0xee17156c, 0x0, 0x0) report_fatal(0x42, 0xfe092000, 0xfe0482a8, 0xee171, 0xfe092000, 0xee1714ac) report_error(0xd4, 0xee170b7c, 0x42, 0xfe028208, 0xfe0ffddc, 0xfe092000) Thread::print(0x580f00, 0xfe092000, 0x1e8, 0xee170, 0xfe092000, 0xee1702ec) os::get_priority(0x580f00, 0xee1702ec, 0xfe092000, 0xee17033c, 0x7fff, 0xfe092000) os::get_native_priority(0x580f00, 0xee170284, 0x0, 0xee170b50, 0x79, 0xee170357) The offending thread doesn't seem to differ in any way (e.g., stack size, priority attributes) from previous Web server request thread which successfully attached itself to JVM. Am I missing some step here? Thanks, Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JVM Error
Hello, I work on JK2 family module for AOLserver and use JNI to communicate with Tomcat, so the JVM is running inside the Web server process. I experience a problem with JVM 1.3.1 on Solaris 2.7/E250 and wonder if anyone else has encountered a similar issue. It manifests itself as JVM crashing, writing a message to the tune HotSpot Virtual Machine Error/Cannot obtain thread information and dumping core due to SIGSEGV. It appears that I can reproduce the error by launching AOLserver with JVM in-process, executing a couple of requests and then letting the server sit idle for about 10 minutes. Subsequent request to Tomcat has a good chance of crashing the server. Examining core in dbx reveals that SEGV always happens in AOLserver request thread, bound to JVM by virtue of using a JNI channel. I can trace the signal to a C++ method, Thread* ThreadLocalStorage::get_thread_via_cache(), local to libjvm.so (debugging data is available if anyone is interested). What could be causing this problem and how can I correct it? I also see a SEGV during JVM initialization. JVM establishes signal handlers to trap and absorb signals, so this one doesn't cause any visible damage. I detect it in dbx and truss, and it seems to originate in JRE library libnet.so evaluating equivalent of C expression *(int*)0. I am puzzled because it looks like intentional dereference of NULL pointer. Your help is appreciated! Alex Typical problem report for the crash: Unexpected Signal : 11 occurred at PC=0xfdcbc5c4 Function name=JVM_Clone Library=/opt/java/jre/lib/sparc/server/libjvm.so Cannot obtain thread information Dynamic libraries: 0x1 bin/nsd 0xff38 /usr/lib/libsocket.so.1 0xff28 /usr/lib/libnsl.so.1 0xff3a /usr/lib/libdl.so.1 0xff35 /usr/lib/librt.so.1 0xff24 /usr/lib/libthread.so.1 0xff20 /usr/lib/libresolv.so.2 0xff1d /usr/lib/libm.so.1 0xff10 /usr/lib/libc.so.1 0xff0e /usr/lib/libmp.so.2 0xff0c /usr/lib/libaio.so.1 0xff33 /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 0xff03 /home/aleykekh/aolserver-3.4-opt/bin/nssock.so 0xfe7e /home/aleykekh/aolserver-3.4-opt/bin/nslog.so 0xfe7c /home/aleykekh/aolserver-3.4-opt/bin/nscgi.so 0xfe75 /home/aleykekh/newtomcat/jakarta-tomcat-connectors-4.1.12-src/jk/build/jk2/aolserver/libnsjk2.so 0xfe70 /home/aleykekh/newtomcat/apache2/lib/libapr-0.so.0 0xfe6c /home/aleykekh/newtomcat/apache2/lib/libaprutil-0.so.0 0xfe68 /usr/local/lib/libexpat.so.0 0xfdc0 /opt/java/jre/lib/sparc/server/libjvm.so 0xfe65 /usr/lib/libCrun.so.1 0xff05 /usr/lib/libw.so.1 0xfe61 /export/0/j2se-1.3.1/jre/lib/sparc/native_threads/libhpi.so 0xfe3d /export/0/j2se-1.3.1/jre/lib/sparc/libverify.so 0xfe39 /export/0/j2se-1.3.1/jre/lib/sparc/libjava.so 0xfe35 /export/0/j2se-1.3.1/jre/lib/sparc/libzip.so 0xfe31 /usr/lib/nss_files.so.1 0xfe5e /home/aleykekh/aolserver-3.4-opt/bin/nscp.so 0xfa7e /export/0/j2se-1.3.1/jre/lib/sparc/libnet.so Local Time = Fri Jan 24 16:28:43 2003 Elapsed Time = 992 # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002CC 01 # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # The Function name at the top of report varies, eg., JVM_GetMethodIxArgsSize, JVM_RawMonitorEnter. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JVM Error
I've seen similar problems - java is very sensitive to each thread beeing 'registered'. My understanding is that attaching the thread will set all the TLDs that are needed, and jk2 is calling the attach method - so I don't know what is wrong here. My bet would be on thread creation - I would add some printf with the TID serving the request ( before attaching the thread ). One thing that may happen in 10 minutes is the thread management code adding or removing threads. Costin Alexander Leyke wrote: Hello, I work on JK2 family module for AOLserver and use JNI to communicate with Tomcat, so the JVM is running inside the Web server process. I experience a problem with JVM 1.3.1 on Solaris 2.7/E250 and wonder if anyone else has encountered a similar issue. It manifests itself as JVM crashing, writing a message to the tune HotSpot Virtual Machine Error/Cannot obtain thread information and dumping core due to SIGSEGV. It appears that I can reproduce the error by launching AOLserver with JVM in-process, executing a couple of requests and then letting the server sit idle for about 10 minutes. Subsequent request to Tomcat has a good chance of crashing the server. Examining core in dbx reveals that SEGV always happens in AOLserver request thread, bound to JVM by virtue of using a JNI channel. I can trace the signal to a C++ method, Thread* ThreadLocalStorage::get_thread_via_cache(), local to libjvm.so (debugging data is available if anyone is interested). What could be causing this problem and how can I correct it? I also see a SEGV during JVM initialization. JVM establishes signal handlers to trap and absorb signals, so this one doesn't cause any visible damage. I detect it in dbx and truss, and it seems to originate in JRE library libnet.so evaluating equivalent of C expression *(int*)0. I am puzzled because it looks like intentional dereference of NULL pointer. Your help is appreciated! Alex Typical problem report for the crash: Unexpected Signal : 11 occurred at PC=0xfdcbc5c4 Function name=JVM_Clone Library=/opt/java/jre/lib/sparc/server/libjvm.so Cannot obtain thread information Dynamic libraries: 0x1 bin/nsd 0xff38 /usr/lib/libsocket.so.1 0xff28 /usr/lib/libnsl.so.1 0xff3a /usr/lib/libdl.so.1 0xff35 /usr/lib/librt.so.1 0xff24 /usr/lib/libthread.so.1 0xff20 /usr/lib/libresolv.so.2 0xff1d /usr/lib/libm.so.1 0xff10 /usr/lib/libc.so.1 0xff0e /usr/lib/libmp.so.2 0xff0c /usr/lib/libaio.so.1 0xff33 /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 0xff03 /home/aleykekh/aolserver-3.4-opt/bin/nssock.so 0xfe7e /home/aleykekh/aolserver-3.4-opt/bin/nslog.so 0xfe7c /home/aleykekh/aolserver-3.4-opt/bin/nscgi.so 0xfe75 /home/aleykekh/newtomcat/jakarta-tomcat-connectors-4.1.12-src/jk/build/jk2/aolserver/libnsjk2.so 0xfe70 /home/aleykekh/newtomcat/apache2/lib/libapr-0.so.0 0xfe6c /home/aleykekh/newtomcat/apache2/lib/libaprutil-0.so.0 0xfe68 /usr/local/lib/libexpat.so.0 0xfdc0 /opt/java/jre/lib/sparc/server/libjvm.so 0xfe65 /usr/lib/libCrun.so.1 0xff05 /usr/lib/libw.so.1 0xfe61 /export/0/j2se-1.3.1/jre/lib/sparc/native_threads/libhpi.so 0xfe3d /export/0/j2se-1.3.1/jre/lib/sparc/libverify.so 0xfe39 /export/0/j2se-1.3.1/jre/lib/sparc/libjava.so 0xfe35 /export/0/j2se-1.3.1/jre/lib/sparc/libzip.so 0xfe31 /usr/lib/nss_files.so.1 0xfe5e /home/aleykekh/aolserver-3.4-opt/bin/nscp.so 0xfa7e /export/0/j2se-1.3.1/jre/lib/sparc/libnet.so Local Time = Fri Jan 24 16:28:43 2003 Elapsed Time = 992 # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002CC 01 # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # The Function name at the top of report varies, eg., JVM_GetMethodIxArgsSize, JVM_RawMonitorEnter. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10759] New: - Tomcat 4.0.3 crashes on JVM error.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10759. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10759 Tomcat 4.0.3 crashes on JVM error. Summary: Tomcat 4.0.3 crashes on JVM error. Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After running for a month, Tomcat crashed without reason with the following output: Unexpected Signal : 11 occurred at PC=0x4040890E Function=at_call__C6PcDesc+0x6 Library=/opt/j2sdk1.4.0/jre/lib/i386/client/libjvm.soCurrent Java thread: at java.lang.Throwable.fillInStackTrace(Native Method) at java.lang.Throwable.init(Throwable.java:180) at java.lang.Exception.init(Exception.java:29) at java.lang.RuntimeException.init(RuntimeException.java:32) at java.lang.NullPointerException.init(NullPointerException.java:36) [error occured during error reporting] Another exception has been detected while we were handling last error. Dumping information about last error: ERROR REPORT FILE = (N/A) PC= 0x0x4040890e SIGNAL= 11 FUNCTION NAME = at_call__C6PcDesc OFFSET= 0x6 LIBRARY NAME = /opt/j2sdk1.4.0/jre/lib/i386/client/libjvm.so Please check ERROR REPORT FILE for further information, if there is any. Good bye.This happened with Tomcat 4.0.3 and Sun JDK 1.4.0, but I had a similar crash with JDK 1.3.1 and an older Tomcat4-Version some time ago (no log unfortunately).It looks like the error happened in the JVM, but it's very unfortunate, that Tomcat and therefore my web-app die silently on it. The should at least be a automatic restart if the JVM reports an error, so that the downtime is minimized. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10759] - Tomcat 4.0.3 crashes on JVM error.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10759. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10759 Tomcat 4.0.3 crashes on JVM error. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-07-12 23:24 --- As usual, VM crashes are not TC bugs, but JVM bugs. Sometimes, this can be triggered by a Tomcat bug, but since this is usually not reproducable, you'll have to isolate the bug for us. The automatic restart is a feature that will hopefully eventually be in the launcher which is developed as part of the commons-daemon project, and we're hoping to use it for Tomcat 5.0. In the meantime, there's not much that can be done other that having some scripts to periodically check that the server is still alive, and restart it when needed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
