Red Hat Bugzilla – Bug 1249412
[abrt] java-1.8.0-openjdk-headless: jni_FatalError(): java killed by SIGABRT
Last modified: 2016-01-11 16:55:58 EST
Version-Release number of selected component:
cmdline: //bin/java -Djava.util.logging.config.file=/opt/servers/apache-tomcat-7.0.57-backend/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xss50M -Xms512M -Xmx512M -Djava.security.egd=file:/dev/urandom -Dlogback.configurationFile=/opt/configuration/logback-backend.xml -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=10.0.17.32 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=/opt/configuration/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/opt/configuration/jmxremote.access -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n -Djava.endorsed.dirs=/opt/servers/apache-tomcat-7.0.57-backend/endorsed -classpath /opt/servers/apache-tomcat-7.0.57-backend/bin/logback/jul-to-slf4j-1.7.12.jar:/opt/servers/apache-tomcat-7.0.57-backend/bin/logback/slf4j-api-1.7.12.jar:/opt/servers/apache-tomcat-7.0.57-backend/bin/logback/logback-classic-1.1.3.jar:/opt/servers/apache-tomcat-7.0.57-backend/bin/logback/logback-core-1.1.3.jar:/opt/servers/apache-tomcat-7.0.57-backend/bin/bootstrap.jar:/opt/servers/apache-tomcat-7.0.57-backend/bin/tomcat-juli.jar -Dcatalina.base=/opt/servers/apache-tomcat-7.0.57-backend -Dcatalina.home=/opt/servers/apache-tomcat-7.0.57-backend -Djava.io.tmpdir=/opt/servers/apache-tomcat-7.0.57-backend/temp org.apache.catalina.startup.Bootstrap start
runlevel: N 5
Thread no. 1 (10 frames)
#3 jni_FatalError at /usr/src/debug/java-1.8.0-openjdk-22.214.171.124-4.b16.fc22.x86_64/openjdk/hotspot/src/share/vm/prims/jni.cpp:862
#4 jniFatalError at /usr/src/debug/java-1.8.0-openjdk-126.96.36.199-4.b16.fc22.x86_64/openjdk/jdk/src/share/back/debugInit.c:671
#5 debugInit_exit at /usr/src/debug/java-1.8.0-openjdk-188.8.131.52-4.b16.fc22.x86_64/openjdk/jdk/src/share/back/debugInit.c:1334
#6 initialize at /usr/src/debug/java-1.8.0-openjdk-184.108.40.206-4.b16.fc22.x86_64/openjdk/jdk/src/share/back/debugInit.c:750
#7 cbEarlyVMInit at /usr/src/debug/java-1.8.0-openjdk-220.127.116.11-4.b16.fc22.x86_64/openjdk/jdk/src/share/back/debugInit.c:458
#8 JvmtiExport::post_vm_initialized at /usr/src/debug/java-1.8.0-openjdk-18.104.22.168-4.b16.fc22.x86_64/openjdk/hotspot/src/share/vm/prims/jvmtiExport.cpp:470
#9 Threads::create_vm at /usr/src/debug/java-1.8.0-openjdk-22.214.171.124-4.b16.fc22.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3622
#10 JNI_CreateJavaVM at /usr/src/debug/java-1.8.0-openjdk-126.96.36.199-4.b16.fc22.x86_64/openjdk/hotspot/src/share/vm/prims/jni.cpp:5201
#11 InitializeJVM at /usr/src/debug/java-1.8.0-openjdk-188.8.131.52-4.b16.fc22.x86_64/openjdk/jdk/src/share/bin/java.c:1214
#12 JavaMain at /usr/src/debug/java-1.8.0-openjdk-184.108.40.206-4.b16.fc22.x86_64/openjdk/jdk/src/share/bin/java.c:376
Created attachment 1058572 [details]
Created attachment 1058573 [details]
Created attachment 1058574 [details]
Created attachment 1058575 [details]
Created attachment 1058576 [details]
Created attachment 1058577 [details]
Created attachment 1058578 [details]
Created attachment 1058579 [details]
Created attachment 1058580 [details]
Created attachment 1058581 [details]
Created attachment 1058582 [details]
Created attachment 1058583 [details]
Hi, do you have multiple instances of the same application running, or another Java app running with debug enabled? It seems that there was a transport error init and in most cases, this is due to more than one application trying to use the same (debug) port.
*** Bug 1252026 has been marked as a duplicate of this bug. ***
Is that a reason to crash??
(In reply to Pavel Alexeev from comment #15)
> Is that a reason to crash??
Not to crash, but it is certainly a reason to not boot because the debug server runs on a TCP port. If multiple VMs are brought up with the same configuration, all but the first will see that the selected port is in use and will refuse to boot.
It will be good catch that, print appropriate message and exit. Now it crashed with SIGABRT.
What is shown on the commandline when it crashes?
Unfortunately I can't say - it is tomcat most likely it is not started from console.
Okay, I wrote a small test program to check console behavior and this is what I see on console when I try to start a second instance with debug server on same port:
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
So there is proper indication to the user as to what happened (the first line). The SIGABRT is secondary behavior and perfectly acceptable here as the JVM boot up was indeed aborted due to a fatal error.
For Tomcat to show the above message, it needs to be fixed/updated to detect it and act accordingly.
I am going to close this bug, but please feel free to re-open and re-assign to Tomcat if you would like it resolved still.
Thank you for the reproduce and detailed answer.
Why you think SIGABRT is correct behavior? Is not exit wit non-0 exit code enough if error caught and processed?
(In reply to Pavel Alexeev from comment #21)
> Thank you for the reproduce and detailed answer.
> Why you think SIGABRT is correct behavior? Is not exit wit non-0 exit code
> enough if error caught and processed?
The JVM does not distinguish between errors when it comes to the JVMTI agent (the system through which debug server is initialized) when debug is requested.
As far as it is concerned, any problem in JVMTI initialization is a fatal error. The code basically expects everything to work/initialize as expected, and sends an abort if there is any issue.
Here is the code in question that calls abort():