Skip to content
This repository has been archived by the owner on Jun 29, 2023. It is now read-only.

Missing type info in the stacktrace #97

Closed
mrmanc opened this issue Nov 16, 2016 · 6 comments
Closed

Missing type info in the stacktrace #97

mrmanc opened this issue Nov 16, 2016 · 6 comments
Labels
type: bug A general bug

Comments

@mrmanc
Copy link

mrmanc commented Nov 16, 2016

We have noticed some missing info in the stacktraces which reach Kibana (via Logstash). I’ve not seen an example with a chained exception where the outermost exception’s stacktrace is printed (but that’s not this issue).

This issue is about the fact that sometimes the type of the exception is missing from the cause, and also sometimes from the outermost exception. I wondered if the StackTraceFilter could be causing the issue with missing types, but I’ve tested that from JUnit and can see that it only filters whole lines, not portions of lines. I’ve attached two example traces below.

There’s significant effort involved in disabling stacktrace filtering and redeploying so I wanted to check if anything jumped out at you first before I attempt to rule out Logback & Logstash. I also no longer have the files these logs got written to so a unable to compare their contents with what I see in Kibana.

The first starts with two lines beginning Exception: , but it looks like it just reports the message, not the exception type.

The second starts okay, but has no actual stack elements for the exception, and no type for the cause.

The logstash-gelf version is 1.9.0.

@mp911de mp911de added the type: bug A general bug label Nov 16, 2016
@mp911de
Copy link
Owner

mp911de commented Nov 16, 2016

This sounds like a bug in the StackTraceFilter. Please disable the filtering as temporary workaround.

@mp911de mp911de added this to the logstash-gelf 1.11.1 milestone Nov 16, 2016
@mrmanc
Copy link
Author

mrmanc commented Nov 16, 2016

Spurred by your speedy response and confidence it’s an issue with the StackTraceFilter I’ve challenged my assumptions and dug into the SOAP library code, checked the printStackTrace() results from an org.apache.axis.AxisFault (as thrown in org.apache.axis.transport.http.HTTPSender.readFromSocket, and I can see now this is caused by AxisFault overriding Throwable.toString().

So so sorry for wasting your time. Going to go and look at the other (more easily reproduced) part of the issue now (missing outer stacktrace) and will let you know how I get on.

@mp911de
Copy link
Owner

mp911de commented Nov 16, 2016

I'm not convinced yet about StackTraceFilter to be bug-free so I'd like to keep that ticket open to dig into the issue.

@mrmanc
Copy link
Author

mrmanc commented Nov 17, 2016

Sure, you may consider this a bug as it’s triggered by how you interact with the Throwable.

Here… have a test case :) I’ve included one for Throwable.printStackTrace() to show the difference.

        <dependency>
            <groupId>org.apache.axis</groupId>
            <artifactId>axis</artifactId>
            <version>1.4</version>
        </dependency>
    @Test
    public void remoteExceptionNotRemovedFromStackTrace() {
        Throwable fault = new org.apache.axis.AxisFault("HTTP", "(401) Some error content", null, null);
        Assert.assertTrue(StackTraceFilter.getFilteredStackTrace(fault).contains("AxisFault"));
    }
    @Test
    public void exceptionNamePresentInPrintedStackTrace() {
        StringWriter stackTraceWriter = new StringWriter();
        Throwable fault = new org.apache.axis.AxisFault("HTTP", "(401) Some error content", null, null);
        fault.printStackTrace(new PrintWriter(stackTraceWriter));
        Assert.assertTrue(stackTraceWriter.toString().contains("AxisFault"));
    }

@mp911de
Copy link
Owner

mp911de commented Dec 3, 2016

Thanks a lot for the concise test case. That should be fixed now with fa075fb7e989057920847dcfc5c91db9b26c9abf . AxisFault dumps additionally the stack trace on its own into the message that is not filtered. You can give the fix a spin with 1.11.1-SNAPSHOT available at https://oss.sonatype.org/content/repositories/snapshots.

@mp911de mp911de closed this as completed Dec 3, 2016
@mrmanc
Copy link
Author

mrmanc commented Dec 3, 2016

Great, I’ll take a look at some point soon and let you know. Thanks for the effort, and I’m pleased the test case was useful.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants