New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only the root cause stack trace is visible in filtered stack traces #99

mrmanc opened this Issue Nov 17, 2016 · 2 comments


2 participants

mrmanc commented Nov 17, 2016

(forked from #98)

I’ve noticed that only the stack trace of the root cause is printed when the stack trace is filtered. Looking at the code this appears to be intentional. I can see someone might only care about the root cause, but I wondered about whether you feel it would be worth separating the ability to filter uninteresting packages from the full stack trace from the ability to present the filtered root cause?

@mrmanc you raised an interesting issue.

I think it could make sense to keep only the trace of the caught exception, the first n exceptions (seen from the caught exception) or the last n exceptions (seen from the root cause exception). This could play nicely with filterStackTrace=1 (keep only 1 exception from the caught side)/filterStackTrace=-1(keep only the first exception from the cause side).

Does this make sense?

While looking at a possible fix for this I because curious about this, and writing a test case to see if I could fix it easily I realised that there is interesting logic in Throwable.printEnclosedStackTrace() around compressing common frames (see ... 29 more in the details below) which you lose by implementing the printing of the stack trace elements yourself. I speculated that you chose this approach to be able to easily restrict the print to the last Throwable in the chain which makes sense.

``` java.lang.Throwable: This is the wrapper at biz.paluch.logging.StackTraceFilterTest.doesNotFilterDoubleThrowable( at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( at at org.junit.runners.model.FrameworkMethod.invokeExplosively( at org.junit.internal.runners.statements.InvokeMethod.evaluate( at org.junit.internal.runners.statements.RunBefores.evaluate( at org.junit.runners.ParentRunner.runLeaf( at org.junit.runners.BlockJUnit4ClassRunner.runChild( at org.junit.runners.BlockJUnit4ClassRunner.runChild( at org.junit.runners.ParentRunner$ at org.junit.runners.ParentRunner$1.schedule( at org.junit.runners.ParentRunner.runChildren( at org.junit.runners.ParentRunner.access$000( at org.junit.runners.ParentRunner$2.evaluate( at at at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs( at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs( at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart( at com.intellij.rt.execution.junit.JUnitStarter.main( at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at com.intellij.rt.execution.application.AppMain.main( Caused by: java.lang.Throwable: This is the cause ... 29 more ```

When printing multiple traces though I think it would be better to simply parser / filter the Throwable output itself to get the benefit of common frame deduplication and adding the package filtering over the top. Making the depth of traces to present would be problematic with this approach as you wouldn’t know whether you were losing frames presented further up the chain which you had chosen to hide. You could solve this by only allowing positive integers and using it to compute the height in the stack to start from (perhaps interpreting 0 as the full height), but this doesn’t seem very useful.

My ‘keep it simple’ instincts suggests allowing the user to choose to invoke Throwable.printStackTrace() on the root cause and filter for packages or to invoke Throwable.printStackTrace() on the first Throwable in the chain and filtering for packages.

mp911de added a commit that referenced this issue Dec 3, 2016

Allow selective stack trace extraction with filtering on Java-default…
… representation #99

logstash-gelf now uses Java-default stack trace representations as input for stack trace filtering. Setting extractStackTrace to a numerical value allows selection of the throwable to be represented. The resulting stack trace of a selected child exception is prepended with all throwables in the chain without their stack trace.

Stack trace printing uses now Java's default representation (Throwable.printStackTrace) to get also suppressed exceptions in the complete stack trace.

@mp911de mp911de added this to the logstash-gelf 1.11.1 milestone Dec 3, 2016


This comment has been minimized.


mp911de commented Dec 3, 2016

That's fixed now with fa075fb. extractStackTrace allows selection of the desired exception (1 for the cause, -1 for the root cause, 2 for the cause's cause and so on.)

@mp911de mp911de closed this Dec 3, 2016


This comment has been minimized.

mrmanc commented Dec 3, 2016

Looks interesting, thanks! I’ll get back to you with feedback for this too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment