[jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
Stefan Erichsen (JIRA)
issues at jboss.org
Tue Nov 25 08:23:40 EST 2014
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022721#comment-13022721 ]
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)
More information about the jboss-jira
mailing list