Skip to content

Unable to parse traceback #38

Open
Open
Unable to parse traceback#38

Description

@joejackson1993
joejackson1993
opened on Aug 4, 2022

I'm trying to use this with a java stack trace, which I think is supported. However, I'm getting an error.

Traceback (most recent call last):
File "/usr/local/bin/git-stacktrace", line 10, in
sys.exit(main())
File "/Library/Python/3.8/site-packages/git_stacktrace/cmd.py", line 78, in main
traceback = api.parse_trace(blob)
File "/Library/Python/3.8/site-packages/git_stacktrace/parse_trace.py", line 254, in parse_trace
raise ParseException("Unable to parse traceback")
git_stacktrace.parse_trace.ParseException: Unable to parse traceback

This is my example stack trace copied from intelliJ
substituteVariables:1779, StringUtil (com.company.util)
substituteVariables:1857, StringUtil (com.company.util)
substituteVariables:1834, StringUtil (com.company.util)
substituteVariableWithNullMethodReturnsEmptyString:439, StringUtilTest (com.company.util)

Activity

  1. jogo commented on Aug 5, 2022

    @jogo
    jogo
    on Aug 5, 2022
    Contributor

    Thanks for the bug report, java support definitely has a some edge cases remaining. If you can provide a full (synthetic?) stack trace that is currently failing I can look into it further.

    The format I have been testing against is something like this (from current tests), so looking for the first line and the 'at' lines

    java.io.FileNotFoundException: foo (The system cannot find the file specified)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.(FileInputStream.java:106)
        at com.devdaily.tests.ExceptionTest.(ExceptionTest.java:15)
        at com.devdaily.tests.ExceptionTest.main(ExceptionTest.java:36)

  2. joejackson1993 commented on Aug 9, 2022

    @joejackson1993
    joejackson1993
    on Aug 9, 2022
    Author

    ok, so having the 'at' helped me get passed the error but the tool still isn't working for me.

    ❯ git stacktrace --since=20.day < ~/Documents/stack1.txt
commit range: 62dc2d4285835fd88e118b20b5df4a6c2b80e43c..0b50b0a989ed1d705cab6ad0eca9953f39fdf658
java.lang.Exception: Dump The Stack
        at com.glide.util.Log.dumpStack(Log.java:376)
        at com.glide.util.Log.dumpStack(Log.java:367)
        at com.glide.util.StringUtil.substituteVariables(StringUtil.java:1855)
        at com.glide.util.StringUtil.substituteVariables(StringUtil.java:1841)
        at com.glide.util.StringUtil.substituteVariables(StringUtil.java:1830)

No matches found

    I made changes to those files 8 days so I'm not sure why it didn't detect them.

  3. joejackson1993 commented on Aug 9, 2022

    @joejackson1993
    joejackson1993
    on Aug 9, 2022
    Author

    It would also be a great enhancement if this could work without other formats. Specifically when copying the stack from a debugger like intelliJ.

  4. jogo commented on Aug 9, 2022

    @jogo
    jogo
    on Aug 9, 2022
    Contributor

    Unfortunately the only way I know how to debug why a match wasn't found is by being able to locally reproduce the issue. which means having a copy of the repo and the trace.

    As for the trace format I personally haven't used intelliJ, so am not familiar with exactly what it does or what format it uses. That being said adding support for this format sounds like a nice enchainment, if you are interested in contributing it.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions