[ https://issues.apache.org/jira/browse/STORM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated STORM-2767: ---------------------------------- Labels: pull-request-available (was: ) > Surefire now truncates too much of the stack trace > -------------------------------------------------- > > Key: STORM-2767 > URL: https://issues.apache.org/jira/browse/STORM-2767 > Project: Apache Storm > Issue Type: Improvement > Affects Versions: 2.0.0 > Reporter: Stig Rohde Døssing > Assignee: Stig Rohde Døssing > Priority: Minor > Labels: pull-request-available > > Surefire is truncating so much of the stack trace when tests fail that we > often can't easily spot the error. As an example I manually threw an NPE from > storm-kafka-client's KafkaSpout.commit() method, and here are the stack > traces with trimStackTrace enabled and disabled: > trimmed > {code} > testCommitSuccessWithOffsetVoids(org.apache.storm.kafka.spout.KafkaSpoutCommitTest) > Time elapsed: 0.714 sec <<< ERROR! > java.lang.NullPointerException: This is an NPE from inside nextTuple > at > org.apache.storm.kafka.spout.KafkaSpoutCommitTest.testCommitSuccessWithOffsetVoids(KafkaSpoutCommitTest.java:87) > {code} > not trimmed > {code} > testCommitSuccessWithOffsetVoids(org.apache.storm.kafka.spout.KafkaSpoutCommitTest) > Time elapsed: 0.78 sec <<< ERROR! > java.lang.NullPointerException: This is an NPE from inside nextTuple > at org.apache.storm.kafka.spout.KafkaSpout.commit(KafkaSpout.java:266) > at > org.apache.storm.kafka.spout.KafkaSpout.nextTuple(KafkaSpout.java:235) > at > org.apache.storm.kafka.spout.KafkaSpoutCommitTest.testCommitSuccessWithOffsetVoids(KafkaSpoutCommitTest.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) > at > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {code} > Note how the trimmed stack trace is also removing the trace lines from inside > KafkaSpout. > As part of fixing https://issues.apache.org/jira/browse/STORM-2734 we > upgraded to Surefire 2.19.1. It seems like 2.19 switched to a different > interpretation of trimStackTrace, which trims all lines outside the test. > It's my impression that it used to only trim lines before the trace reached a > line inside the test. Going by > https://issues.apache.org/jira/browse/SUREFIRE-1226?focusedCommentId=15140710&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15140710, > this change seems intentional. > We should either downgrade Surefire, or disable stack trace trimming. -- This message was sent by Atlassian JIRA (v6.4.14#64029)