Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1198186 - [GSS] (6.4.z) JBoss does not log stack trace of an exception
Summary: [GSS] (6.4.z) JBoss does not log stack trace of an exception
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.3.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR1
: EAP 6.4.3
Assignee: Tomas Hofman
QA Contact: Martin Simka
URL:
Whiteboard:
Depends On:
Blocks: 1231259
TreeView+ depends on / blocked
 
Reported: 2015-03-03 14:15 UTC by Tom Ross
Modified: 2019-04-16 14:39 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-17 10:36:58 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFCORE-587 0 Major Resolved Wildfly does not log stack trace of an exception 2016-03-02 04:49:24 UTC

Description Tom Ross 2015-03-03 14:15:00 UTC
AbstractOperationContext.java line 1159 seems to be "swallowing" exceptions. It's possible to get NullPointerException without a stack trace. This makes it impossible to trace the cause of the NPE. 

https://github.com/jbossas/jboss-eap/blob/2292b0a8763683d0fab03efc3de6a29b974c09eb/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L1159

2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-11) Finding class org.jboss.logging.DelegatingBasicLogger from Module "org.picketbox:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
2015-02-27 12:53:26,586 ERROR [|] [org.jboss.as.controller.client] (ServerService Thread Pool -- 29) JBAS014781: Step handler org.jboss.as.controller.AbstractAddStepHandler$1@1e6a7c88 for operation {"operation" => "add","factory-class" => "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory","param" => [("host" => "tp4.app.paypoint.net"),("port" => "6495"),("use-nio" => "true")],"address" => [("subsystem" => "messaging"),("hornetq-server" => "default"),("connector" => "tp4")],"socket-binding" => undefined} at address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("connector" => "tp4")
] failed handling operation rollback -- java.lang.NullPointerException
2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-4) Finding class org.jboss.remoting3.UnlockedReadHashMap$EntryIterator from Module "org.jboss.remoting3:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))

Comment 1 Tomas Hofman 2015-03-09 14:28:10 UTC
Created upstream issue: https://issues.jboss.org/browse/WFCORE-587

Comment 2 Tomas Hofman 2015-03-13 10:03:17 UTC
Reporting message was left as it was - it's supposed to go to a client and Brian doesn't want it to contain stack traces. Instead, the message is additionally logged in server log, this time with a stack trace.

Comment 3 Tomas Hofman 2015-03-13 10:08:16 UTC
PR: https://github.com/jbossas/jboss-eap/pull/2352

Comment 4 Tomas Hofman 2015-04-23 09:50:45 UTC
Fixed PR: https://github.com/jbossas/jboss-eap/pull/2400

Noticed there was an extra commit in the original one.

Comment 5 Tomas Hofman 2015-04-27 08:59:37 UTC
I'm sorry for not having automated test for this issue. I consulted with Martin Simka, and we concluded that byteman rule could be an appropriate way of reproducing this.

So, the recipe for reproducer is following:

1) Start EAP.
2) Install byteman:

bminstall.sh -b -Dorg.jboss.byteman.transform.all {EAP_process_ID}

2) Load following byteman rule:

RULE break result handler
CLASS org.jboss.as.controller.OperationContext$ResultHandler$1
METHOD handleResult
AT EXIT
IF true
DO traceln("breaking at " + java.util.Arrays.toString(Thread.currentThread().getStackTrace()));
   throw new java.lang.RuntimeException("test exception")
ENDRULE

with command:

bmsubmit.sh -l file_with_byteman_rule.btm 

3) Within couple of seconds, following error message should be printed in standard output as well as in server.log, together with its' stack trace.

10:20:57,347 ERROR [org.jboss.as.controller.management-operation] (DeploymentSca
nner-threads - 1) JBAS014781: Step handler org.jboss.as.controller.ModelControll
erImpl$DefaultPrepareStepHandler@796dcbb9 for operation {"operation" => "read-ch
ildren-resources","address" => [],"child-type" => "deployment","include-runtime"
 => undefined,"recursive" => undefined,"recursive-depth" => undefined,"proxies" 
=> undefined,"include-defaults" => undefined} at address [] failed handling oper
ation rollback -- java.lang.RuntimeException: test exception: java.lang.RuntimeE
xception: test exception
...


The message should be repeated every couple of seconds, since it's triggered by deployment scanner in this case. When using the EAP version before the fix, no error message appears at all.

Comment 8 Jan Martiska 2015-07-30 14:12:45 UTC
Verified in EAP 6.4.3.CR1.

Comment 9 Petr Penicka 2017-01-17 10:36:58 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 10 Petr Penicka 2017-01-17 10:37:31 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.


Note You need to log in before you can comment on or make changes to this bug.