[
https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s...
]
Stefan Erichsen commented on WFLY-825:
--------------------------------------
Hi Tomar,
thanks for your quick response. Unfortunately WildFly 8.1.0.Final and 8.2.0.Final
won't even start on the machine.
{code:java}
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /wildfly-8.2.0.Final
JAVA: /QOpenSys/QIBM/ProdData/JavaVM/jdk70/64bit/bin/java
JAVA_OPTS: -Xms64m -Xmx2048m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true
-Djboss.modules.system.pkgs=org.jboss.bytema
n -Djava.awt.headless=true -Xdebug
-Xrunjdwp:transport=dt_socket,address=5051,server=y,suspend=n
=========================================================================
Listening for transport dt_socket at address: 5051
[0m14:16:54,330 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
[0m [0m14:16:55,150 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final
[0m [0m14:16:55,251 INFO [org.jboss.as] (MSC service thread 1-8) JBAS015899: WildFly
8.2.0.Final "Tweek" starting
[0m [0m14:16:58,363 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888:
Creating http management service using socket-binding (management-http)
[0m [0m14:16:58,392 INFO [org.xnio] (MSC service thread 1-4) XNIO version 3.3.0.Final
[0m [0m14:16:58,412 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation
Version 3.3.0.Final
[0mUnhandled exception
Type=Illegal instruction vmState=0x00040000
J9Generic_Signal_Number=00000010 Signal_Number=00000004 Error_Value=00000000
Signal_Code=00000009
Handler1=09001000A0248020 Handler2=09001000A023F518
R0=F9A052647CFFF7E0 R1=00000001832E5CF0 R2=00000000000002E6 R3=FFFFFFFFFFFFFFFF
R4=FFFFFFFFFFFFFFFF R5=0000000000002000 R6=00000001859B51E0 R7=0000000000000003
R8=000000018499BED4 R9=09001000A02798E8 R10=000000018499BED4 R11=0000000000003610
R12=0000000000000102 R13=00000001832EF800 R14=00000001859B51B0 R15=00000001832F3F00
R16=0000000000000007 R17=0000000000000000 R18=09001000A024C6D0 R19=09001000A0453020
R20=0000000185B0F250 R21=00000001859B51E0 R22=00000001832F3FF0 R23=0000000000000000
R24=000000000000007E R25=09001000A0241DD0 R26=000000000000007E R27=00000001832E7680
R28=0000000000000002 R29=09001000A0248020 R30=00000001832E6440 R31=0000000000040000
IAR=0000000000003618 LR=090000000282E4D8 MSR=800000000000F032 CTR=0000000000003610
CR=8200004B32000001 FPSCR=8200000000000000 XER=3200000182000000
FPR0 0000000082000000 (f: 2181038080,000000, d: 1,077576e-314)
FPR1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR2 41e8630000000000 (f: 0,000000, d: 3,273130e+09)
FPR3 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR4 41d3729e61400000 (f: 1631584256,000000, d: 1,305115e+09)
FPR5 4323575afd29b546 (f: 4247368960,000000, d: 2,722036e+15)
FPR6 00000000000a74c0 (f: 685248,000000, d: 3,385575e-318)
FPR7 4124e98000000000 (f: 0,000000, d: 6,852480e+05)
FPR8 000000005474814a (f: 1416921472,000000, d: 7,000522e-315)
FPR9 41d51d2052800000 (f: 1384120320,000000, d: 1,416921e+09)
FPR10 43128bfb13208000 (f: 320897024,000000, d: 1,305115e+15)
FPR11 000000004dca7985 (f: 1305115008,000000, d: 6,448125e-315)
FPR12 40b0000000000000 (f: 0,000000, d: 4,096000e+03)
FPR13 4020800000000000 (f: 0,000000, d: 8,250000e+00)
FPR14 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR15 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR16 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR17 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR18 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR19 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR20 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR21 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR22 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR23 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR24 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR25 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR26 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR27 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR28 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR29 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR30 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR31 0000000000000000 (f: 0,000000, d: 0,000000e+00)
Target=2_60_20121024_126071 (OS/400 V7R1M0)
CPU=ppc64 (4 logical CPUs) (0x4c0000000 RAM)
----------- Stack Backtrace -----------
.VMprJavaSendNative (0x09000000008153D4 [libj9vm26.so+0x933d4])
.java_lang_J9VMInternals_initializeImpl (0x09000000025BC924 [libjclse7b_26.so+0x1d924])
.java_lang_J9VMInternals_newInstanceImpl (0x09000000025BC430 [libjclse7b_26.so+0x1d430])
javaProtectedThreadProc+0x13c (0x0900000000788BC0 [libj9vm26.so+0x6bc0])
j9sig_protect+0x38c (0x090000000091CF30 [libj9prt26.so+0x2f30])
javaThreadProc+0x70 (0x09000000007889F4 [libj9vm26.so+0x69f4])
thread_wrapper+0x14c (0x09000000008ED410 [libj9thr26.so+0x3410])
_pthread_body+0x100 (0x09000000003CAD64 [libpthreads.a+0x3d64])
---------------------------------------
JVMDUMP039I
JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von System mit
"/core.20141125.141658.80445.0001.dmp" an
JVMDUMP010I Speicherauszug von System in /core.20141125.141658.80445.0001.dmp geschrieben
JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von Java mit
"/javacore.20141125.141658.80445.0002.txt" an
JVMDUMP010I Speicherauszug von Java in /javacore.20141125.141658.80445.0002.txt
geschrieben
JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von Snap mit
"/Snap.20141125.141658.80445.0003.trc" an
JVMDUMP010I Speicherauszug von Snap in /Snap.20141125.141658.80445.0003.trc geschrieben
JVMDUMP013I Speicherauszugsereignis "gpf", Detail "" wurde
verarbeitet.
{code}
JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
--------------------------------------------------------
Key: WFLY-825
URL:
https://issues.jboss.org/browse/WFLY-825
Project: WildFly
Issue Type: Bug
Components: Server
Environment: operating system - z/OS version 1.13
JDK version info:
java version "1.7.0"
Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR2_20120809_0948_B118929
JIT - r11.b01_20120808_24925
GC - R26_Java726_SR2_20120809_0948_B118929
J9CL - 20120809_118929)
JCL - 20120831_02 based on Oracle 7u3-b05
Reporter: Bob Bennett
Assignee: Jason Greene
Labels: jboss
Attachments: relevant-threads.txt, threadstacks.txt,
xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start
the standalone server, it gets stuck and never completes initialization. It also does not
respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I
opened an issue with IBM support, and here is their response:
Hi Bob,
Have you contacted JBoss support for this issue?
From my review of the javacore, every application-related thread is
waiting on some kind of internal state monitoring code. The most
prominent cause of waiting appears to be a CountdownLatch used in:
org/jboss/as/controller/ParallelBootOperationStepHandler
$ParallelBootTransactionControl.operationPrepared
A quick search found this possibly related JBoss bug which was
introduced because of incompatibilities with Java 7 (although it would appear to have
been fixed before your current build, but I'm not certain
how.)
https://issues.jboss.org/browse/AS7-2940?_sscc=t
The CountdownLatch is one of the Concurrency classes, and is very
simplistic in that it allows an application to direct threads to wait
until some certain number of actions have occured. The application code
(JBoss in this case) would need to explain how many countdowns are
required and which piece of code decrements the counter as needed.
There's not much to say from a JVM perspective other than the threads
are all waiting for an application-level event (a call to the
"countDown()" method 'N' times where 'N' is how many JBoss
initialized
the CountDownLatch to originally.)
If the JBoss team believes there is a specific thread not processing for one reason or
another, we could look at that from a JVM perspective to see why. Unfortunately we'd
need the JBoss team to explain which thread
they think should be executing and why. A system dump of the problem
(taken using signal 3, or from the operator console) would potentially allow for the
internal state variables associated here to be read out...
but that won't really be of any use if we don't know what JBoss expects
them to be.
Regards,
Java Defect Support
Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)