Skip to content
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

NullPointerException when parsing log #314

Closed
punx120 opened this issue Dec 24, 2019 · 10 comments
Closed

NullPointerException when parsing log #314

punx120 opened this issue Dec 24, 2019 · 10 comments

Comments

@punx120
Copy link

punx120 commented Dec 24, 2019

Hi,

Using the latest code of jitwatch - I have a NPE in ParseUtil.java because componentType is null:
if (componentType.isAssignableFrom(sigParamClass))

I added a simple if and it seems that memParamClass is "boolean".

I'm running 1.8.0 192.

Let me know if need something else.

Thanks

@chriswhocodes
Copy link
Member

Hi @punx120, thank you for reporting this bug. Please could you post the stack trace here so I can understand the code path taken to this NPE?

Many thanks,

Chris

@punx120
Copy link
Author

punx120 commented Dec 28, 2019

Here you go:

    Exception in thread "Thread-4" java.lang.NullPointerException
    at org.adoptopenjdk.jitwatch.util.ParseUtil.paramClassesMatch(ParseUtil.java:548)
    at org.adoptopenjdk.jitwatch.model.AbstractMetaMember.matchesSignature(AbstractMetaMember.java:197)
    at org.adoptopenjdk.jitwatch.model.JITDataModel.findMetaMember(JITDataModel.java:223)
    at org.adoptopenjdk.jitwatch.util.ParseUtil.findMemberWithSignature(ParseUtil.java:339)
    at org.adoptopenjdk.jitwatch.parser.AbstractLogParser.findMemberWithSignature(AbstractLogParser.java:246)
    at org.adoptopenjdk.jitwatch.parser.AbstractLogParser.handleMember(AbstractLogParser.java:468)
    at org.adoptopenjdk.jitwatch.parser.AbstractLogParser.handleMethodLine(AbstractLogParser.java:462)
    at org.adoptopenjdk.jitwatch.parser.AbstractLogParser.handleTagQueued(AbstractLogParser.java:369)
    at org.adoptopenjdk.jitwatch.parser.hotspot.HotSpotLogParser.handleTag(HotSpotLogParser.java:307)
    at org.adoptopenjdk.jitwatch.parser.hotspot.HotSpotLogParser.parseLogCompilationLines(HotSpotLogParser.java:135)
    at org.adoptopenjdk.jitwatch.parser.hotspot.HotSpotLogParser.parseLogFile(HotSpotLogParser.java:111)
    at org.adoptopenjdk.jitwatch.parser.AbstractLogParser.processLogFile(AbstractLogParser.java:362)
    at org.adoptopenjdk.jitwatch.ui.main.JITWatchUI$1.run(Unknown Source)

`

@chriswhocodes
Copy link
Member

Hi @punx120
Would you mind doing a clean git clone and build of JITWatch?
The line numbers in your stack trace don't match the latest source code so I just need to make sure you're using the latest source.

git clone https://github.com/AdoptOpenJDK/jitwatch
cd jitwatch
mvn clean package

I do agree that it is possible for an NPE on that check since getComponentType can return null but I would like to understand how it got into the state where it thought it was parsing a varargs parameter:

// check assignable
Class<?> componentType = memParamClass.getComponentType();

if (componentType.isAssignableFrom(sigParamClass))

Could you possibly provide the log file you were parsing please?

Thanks,

Chris

@chriswhocodes
Copy link
Member

I've added a null check to the isAssignableFrom test.

@punx120
Copy link
Author

punx120 commented Jan 14, 2020

Thank you chris.

The initial stack trace was probably taken with an old version - but when i re-ran it with the latest - I had a similar stack trace.

This happened when parsing a log from one of the app at my job - and unfortunately, i'm afraid it'd be difficult to share it.

@chriswhocodes
Copy link
Member

I've re-opened the issue.
Can you post the new stack trace please?
Thanks,
Chris

@chriswhocodes chriswhocodes reopened this Jan 16, 2020
@punx120
Copy link
Author

punx120 commented Jan 17, 2020

You mean with a version just before your "last" commit?

@chriswhocodes
Copy link
Member

Hi @punx120 I mean could you show me the stack trace you get when you test with the very latest commit that includes the guard I added.

If it is still throwing exceptions with this guard I will investigate further.

Thanks,

Chris

@punx120
Copy link
Author

punx120 commented Jan 18, 2020

Sorry for the confusion - here's what happened:

  1. Parse a log file with old version - NPE, stack trace pasted above
  2. Tried to parse the same log with latest - crashed too
  3. Built jitwatch locally with a patch similar to the one your committed - no crash

I haven't tried with a version built from master, but i'm fairly confident it won't crash. I can give it a try if you want. I can also try to give you a stack trace with a verison built before the commit.

Long story short, I think it's fine to close that issue.

@chriswhocodes
Copy link
Member

OK thanks for confirming. Closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants