abrt version: 1.1.14 architecture: i686 Attached file: backtrace cmdline: java -Dprogram.name=run.sh -server -Xms1303m -Xmx1303m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.library.path=/home/jfclere/JBPAPP_5_1/build/output/jboss-5.1.0.Branch/native/lib -Djava.endorsed.dirs=/home/jfclere/JBPAPP_5_1/build/output/jboss-5.1.0.Branch/lib/endorsed -classpath /home/jfclere/JBPAPP_5_1/build/output/jboss-5.1.0.Branch/bin/run.jar org.jboss.Main -b localhost -c default component: java-1.6.0-openjdk crash_function: os::abort executable: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java kernel: 2.6.35.9-64.fc14.i686 package: java-1.6.0-openjdk-1:1.6.0.0-49.1.9.3.fc14 rating: 4 reason: Process /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java was killed by signal 6 (SIGABRT) release: Fedora release 14 (Laughlin) time: 1292408261 uid: 500 How to reproduce ----- 1. starting AS5.1 with JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n" 2. 3.
Created attachment 468830 [details] File: backtrace
Is this error consistent, intermittent or one time?
It seems I am not able to reproduce it today.
I have it again today. Do you need something?
Yes, do you have an hs_err* file for the crash? If so, can you please attach it? It should contain some more information.
Package: java-1.6.0-openjdk-1:1.6.0.0-49.1.9.3.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. start tomcat twice the second cores. 2. 3.
Hi, is there an hs_err* file you can attach for this issue?
No it wasn't created with his crash.
*** Bug 784894 has been marked as a duplicate of this bug. ***
Backtrace analysis found this bug to be similar to some already closed bugs from other components. You might want to check those bugs for additional information. Bugs which were found to be similar to this bug: java-1.6.0-openjdk: bug #575886, bug #604857, bug #605907, bug #638011, bug #679687, bug #708311 java-1.7.0-openjdk: bug #784894 This comment is automatically generated.
happens everytime when stopping JVM in debug mode backtrace_rating: 4 Package: java-1.7.0-openjdk-devel-1.7.0.3-2.1.fc17.7 Architecture: x86_64 OS Release: Fedora release 17 (Beefy Miracle)
Created attachment 589946 [details] File: backtrace
(In reply to comment #11) > happens everytime when stopping JVM in debug mode > > backtrace_rating: 4 > Package: java-1.7.0-openjdk-devel-1.7.0.3-2.1.fc17.7 > Architecture: x86_64 > OS Release: Fedora release 17 (Beefy Miracle) Hi. Are you sure there isn't another debug session running? Your trace looks different and it appears to be happening due to network resource conflict.
I am absolutelu sure that there is no other debug sessions. I tried a million times and spend the whole day trying to investigate this problem - no use. It happens every time when you run Java in debug mode and then when you stop it it crashes with the following message: "Disconnected from the target VM, address: '127.0.0.1:8000', transport: 'socket' /opt/tomcat7/bin/catalina.sh stop ERROR: transport error 202: connect failed: Connection refused ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:741] FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) /opt/tomcat7/bin/catalina.sh: line 439: 2203 Aborted (core dumped) "/usr/lib/jvm/java-1.7.0/bin/java" -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,suspend=y,server=n -Xms512m -Xmx1024m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs="/opt/tomcat7/endorsed" -classpath "/opt/tomcat7/bin/bootstrap.jar:/opt/tomcat7/bin/tomcat-juli.jar" -Dcatalina.base="/home/awajda/.IntelliJIdea11/system/tomcat/Run_HI_(1)_HI-search" -Dcatalina.home="/opt/tomcat7" -Djava.io.tmpdir="/opt/tomcat7/temp" org.apache.catalina.startup.Bootstrap stop" The Java process is left running and "kill" is the only way to stop it. I'm having the same problem on both my laptops (both running F17): one was upgraded from F16 and the other one has a clean F17 installation.
The strange thing is that the debug itself is working and the first message in the Tomcat logs says: /opt/tomcat7/bin/catalina.sh run Connected to the target VM, address: '127.0.0.1:8000', transport: 'socket' Jun 06, 2012 8:51:36 PM org.apache.catalina.core.AprLifecycleListener init So the port is correct, host is correct, debug is working, but just does not stop property and ends up hanging.
(In reply to comment #14) > "/usr/lib/jvm/java-1.7.0/bin/java" -Xdebug > -Xrunjdwp:transport=dt_socket,address=8000,suspend=y,server=n This line (part of the command you ran) looks strange. Did you mean "server=y" and "suspend=n" ?
No, that part is set automatically by IDE (IDEA in my case). I don't know why server=n, but I don't think it related to the problem. suspend=y is also Ok as IDE connects to it as soon as JVM is up. Regarding the problem - I seem to have found a workaround. Presumably it is caused by the IDE issue, but nevertheless JVM shouldn't been crashing with fatal error. So it's rather inadequate error handling sort of issue of JVM. I happened to have JAVA_OPTS variable to be set twice in my IDE Tomcat run/debug profile. Like this: JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:53225,suspend=y,server=n JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:53225,suspend=y,server=n -Xms512m -Xmx1024m -XX:MaxPermSize=256m The second one supposed to be overriding the first one, and it worked well on other OS's, but for some weird reason on my fresh F17 this causes the JVM to crash on shutdown presumably because IDE analyses those two variables separately(?) and tries to connect/disconnect twice to/from the same address, I don't know... that's all my guessing. To work it around I got rid of overriding JAVA_OPTS and replaced the 2nd one with the CATALINA_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=256m. For Tomcat it is essentially the same as in the catalina.sh script $JAVA_OPTS is directly followed by $CATALINA_OPTS resulting in the same sequence of JVM command line arguments, but the JVM crash gone know.
Port 8000 is most likely taken by tomcat itself. In the 'workaround' you use another port, that's probably why it works. It should not crash though, but print out that the address is already in use.
Starting up Glassfish 3.1.2 in debug mode from Netbeans 7.1.2 backtrace_rating: 4 Package: java-1.7.0-openjdk-devel-1.7.0.3-2.2.1.fc17.8 Architecture: x86_64 OS Release: Fedora release 17 (Beefy Miracle)
Starting Glassfish 3.1.2 in debug mode from Netbeans 7.1.2 backtrace_rating: 4 Package: java-1.7.0-openjdk-devel-1.7.0.3-2.2.1.fc17.8 Architecture: x86_64 OS Release: Fedora release 17 (Beefy Miracle)
Hi Florian, have you tried it with another port as mentioned in comment 18?
ERROR: transport error 202: bind failed: Adresse déjà utilisée --->>>> adress 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 [../../../src/share/back/debugInit.c:741] FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) backtrace_rating: 4 Package: java-1.7.0-openjdk-devel-1.7.0.3-2.2.1.fc17.8 Architecture: x86_64 OS Release: Fedora release 17 (Beefy Miracle)
Looks like the JDWP port you are attempting to use is already in use by another (Java?) process. Please check the output of 'netstat -ant' to confirm and kill that process first.
Created attachment 609917 [details] open-jdk error log When i use eclipse, the eclipse exit with an error report on java(open jdk), and a error log reported. See attachment.
(In reply to comment #24) > Created attachment 609917 [details] > open-jdk error log > > When i use eclipse, the eclipse exit with an error report on java(open jdk), > and a error log reported. See attachment. That trace seems unrelated to this issue. Please open a separate bug against the eclipse component for that as it is coming form native code outside of OpenJDK's control.