Bug 1249412

Summary: [abrt] java-1.8.0-openjdk-headless: jni_FatalError(): java killed by SIGABRT
Product: [Fedora] Fedora Reporter: Pavel Alexeev <pahan>
Component: java-1.8.0-openjdkAssignee: Deepak Bhole <dbhole>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: ahughes, dbhole, jerboaa, jvanek, msrb, omajid, psakar
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/94a80d3683a5dd12379d61da7e1aa18652f53de5
Whiteboard: abrt_hash:62ee3a4e2f7f9b1840f64e8c0c16a8a0d8662162
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-11 19:59:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: mountinfo
none
File: namespaces
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Pavel Alexeev 2015-08-02 17:05:25 UTC
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

Comment 1 Pavel Alexeev 2015-08-02 17:05:30 UTC
Created attachment 1058572 [details]
File: backtrace

Comment 2 Pavel Alexeev 2015-08-02 17:05:31 UTC
Created attachment 1058573 [details]
File: cgroup

Comment 3 Pavel Alexeev 2015-08-02 17:05:33 UTC
Created attachment 1058574 [details]
File: core_backtrace

Comment 4 Pavel Alexeev 2015-08-02 17:05:34 UTC
Created attachment 1058575 [details]
File: dso_list

Comment 5 Pavel Alexeev 2015-08-02 17:05:36 UTC
Created attachment 1058576 [details]
File: environ

Comment 6 Pavel Alexeev 2015-08-02 17:05:37 UTC
Created attachment 1058577 [details]
File: limits

Comment 7 Pavel Alexeev 2015-08-02 17:05:38 UTC
Created attachment 1058578 [details]
File: maps

Comment 8 Pavel Alexeev 2015-08-02 17:05:40 UTC
Created attachment 1058579 [details]
File: mountinfo

Comment 9 Pavel Alexeev 2015-08-02 17:05:41 UTC
Created attachment 1058580 [details]
File: namespaces

Comment 10 Pavel Alexeev 2015-08-02 17:05:43 UTC
Created attachment 1058581 [details]
File: open_fds

Comment 11 Pavel Alexeev 2015-08-02 17:05:45 UTC
Created attachment 1058582 [details]
File: proc_pid_status

Comment 12 Pavel Alexeev 2015-08-02 17:05:46 UTC
Created attachment 1058583 [details]
File: var_log_messages

Comment 13 Deepak Bhole 2015-08-04 13:41:34 UTC
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.

Comment 14 Petr Sakaƙ 2015-08-10 13:52:37 UTC
*** Bug 1252026 has been marked as a duplicate of this bug. ***

Comment 15 Pavel Alexeev 2015-12-07 20:27:53 UTC
Is that a reason to crash??

Comment 16 Deepak Bhole 2015-12-07 20:31:59 UTC
(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.

Comment 17 Pavel Alexeev 2016-01-06 11:53:58 UTC
It will be good catch that, print appropriate message and exit. Now it crashed with SIGABRT.

Comment 18 Deepak Bhole 2016-01-06 19:36:21 UTC
What is shown on the commandline when it crashes?

Comment 19 Pavel Alexeev 2016-01-07 13:33:50 UTC
Unfortunately I can't say - it is tomcat most likely it is not started from console.

Comment 20 Deepak Bhole 2016-01-11 19:59:59 UTC
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.

Comment 21 Pavel Alexeev 2016-01-11 21:36:54 UTC
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?

Comment 22 Deepak Bhole 2016-01-11 21:55:58 UTC
(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