Version-Release number of selected component: java-1.8.0-openjdk-headless-1.8.0.51-4.b16.fc22 Additional info: reporter: libreport-2.6.2 backtrace_rating: 4 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 crash_function: jni_FatalError executable: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.51-4.b16.fc22.x86_64/jre/bin/java global_pid: 23424 kernel: 4.1.2-200.hu.1.pf1.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #3 jni_FatalError at /usr/src/debug/java-1.8.0-openjdk-1.8.0.51-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-1.8.0.51-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-1.8.0.51-4.b16.fc22.x86_64/openjdk/jdk/src/share/back/debugInit.c:1334 #6 initialize at /usr/src/debug/java-1.8.0-openjdk-1.8.0.51-4.b16.fc22.x86_64/openjdk/jdk/src/share/back/debugInit.c:750 #7 cbEarlyVMInit at /usr/src/debug/java-1.8.0-openjdk-1.8.0.51-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-1.8.0.51-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-1.8.0.51-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-1.8.0.51-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-1.8.0.51-4.b16.fc22.x86_64/openjdk/jdk/src/share/bin/java.c:1214 #12 JavaMain at /usr/src/debug/java-1.8.0-openjdk-1.8.0.51-4.b16.fc22.x86_64/openjdk/jdk/src/share/bin/java.c:376
Created attachment 1058572 [details] File: backtrace
Created attachment 1058573 [details] File: cgroup
Created attachment 1058574 [details] File: core_backtrace
Created attachment 1058575 [details] File: dso_list
Created attachment 1058576 [details] File: environ
Created attachment 1058577 [details] File: limits
Created attachment 1058578 [details] File: maps
Created attachment 1058579 [details] File: mountinfo
Created attachment 1058580 [details] File: namespaces
Created attachment 1058581 [details] File: open_fds
Created attachment 1058582 [details] File: proc_pid_status
Created attachment 1058583 [details] File: var_log_messages
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(): http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/b95e325137b4/src/share/back/debugInit.c#l1311