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.

Sign up for GitHub

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

Jump to bottom

StackOverflowError during "Find Usages" #7331

Open
herkrath opened this issue Apr 25, 2024 · 7 comments
Open

StackOverflowError during "Find Usages" #7331

herkrath opened this issue Apr 25, 2024 · 7 comments
Labels
Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) kind:bug Bug report or fix nb-javac Run nb-javac integration tests

Comments

@herkrath
Copy link
Contributor

Apache NetBeans version

Apache NetBeans 22 release candidate

What happened

Most likely due to #7153, a StackOverflowError happens when I select "Find Usages" on certain methods of our rather large Java project. As a result, no usages are found, even though there are many. It happens so many times that NetBeans is nearly unusable. As I like NB so much, I often fall back to the text-based "Find...", but that is not a decent replacement obviously.

Note that it is not really worse as compared to before #7153. Before, the same NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.getThrownTypes() because "tree.meth.type" is null error occurred as in #3725 but during "Find Usages". #3725 was supposed to be fixed by #7153.

It started about 2 years ago (I am always using the most recent NB version) but got worse and worse over time. Not sure if that was due to NB, changes in our code or both.

Language / Project Type / NetBeans Component

Java multi-module Maven project

How to reproduce

I created this issue as a heads-up to show probable consequences of #7153. I cannot send our code as it's proprietary and too large.

I will try to identify the culprit (I think it's about generics) and write simple classes to reproduce next.

Did this work correctly in an earlier version?

No / Don't know

Operating System

Windows 11

JDK

Oracle JDK 11.0.22 for the project, Amazon Corretto OpenJDK 17.0.10 for NetBeans

Apache NetBeans packaging

Apache NetBeans binary zip

Anything else

The exception details are:

java.lang.IllegalStateException: java.lang.StackOverflowError
	at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
	at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:765)
	at org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:426)
	at org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:90)
	at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin$FindTask.run(JavaWhereUsedQueryPlugin.java:562)
	at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin$FindTask.run(JavaWhereUsedQueryPlugin.java:540)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.lambda$processFiles$2(JavaRefactoringPlugin.java:330)
	at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:504)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
	at org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:235)
	at org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:205)
	at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
	at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
	at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
	at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
	at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
	at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
	at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
	at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:85)
	at org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:454)
	at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:425)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:328)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:264)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.queryFiles(JavaRefactoringPlugin.java:254)
	at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin.prepare(JavaWhereUsedQueryPlugin.java:353)
	at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare2(AbstractRefactoring.java:417)
	at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:401)
	at org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:212)
	at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$Prepare$2.run(ParametersPanel.java:1059)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1420)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2035)
Caused by: java.lang.StackOverflowError
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1082)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1074)
	at com.sun.tools.javac.code.Types.isSuperType(Types.java:1301)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1083)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1074)
	at com.sun.tools.javac.code.Types.isSuperType(Types.java:1301)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1083)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1074)
	at com.sun.tools.javac.code.Types.isSuperType(Types.java:1301)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1083)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:1074)
	at com.sun.tools.javac.code.Types.isSuperType(Types.java:1301)
        ...

With NetBeans 21, it was:

java.lang.IllegalStateException: java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.getThrownTypes()" because "tree.meth.type" is null
	at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
	at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:765)
	at org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:426)
	at org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:90)
	at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin$FindTask.run(JavaWhereUsedQueryPlugin.java:562)
	at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin$FindTask.run(JavaWhereUsedQueryPlugin.java:540)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.lambda$processFiles$2(JavaRefactoringPlugin.java:330)
	at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:504)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
	at org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:169)
	at org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:140)
	at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
	at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
	at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
	at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
	at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
	at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
	at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
	at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:85)
	at org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:454)
	at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:425)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:328)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:264)
	at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.queryFiles(JavaRefactoringPlugin.java:254)
	at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin.prepare(JavaWhereUsedQueryPlugin.java:353)
	at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare2(AbstractRefactoring.java:417)
	at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:401)
	at org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:212)
	at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$Prepare$2.run(ParametersPanel.java:1059)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1420)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2035)
Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.getThrownTypes()" because "tree.meth.type" is null
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply(Flow.java:1769)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1816)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:455)
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitReturn(Flow.java:1745)
	at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1728)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:455)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:58)
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitBlock(Flow.java:1494)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1092)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:455)
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitMethodDef(Flow.java:1460)
	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:916)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:455)
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:1423)
	at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:814)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:455)
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1862)
	at com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1852)
	at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:231)
	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1419)
	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1383)
	at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:404)
	at com.sun.tools.javac.api.JavacTaskImpl.lambda$analyze$1(JavacTaskImpl.java:379)
	at com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
	at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:379)
	... 32 more

Are you willing to submit a pull request?

No
@herkrath herkrath added kind:bug Bug report or fix needs:triage Requires attention from one of the committers labels Apr 25, 2024
@herkrath
Copy link
Contributor Author

I think I have identified the trigger: Besides our main multi-module project, I had another project open, being the Lucene demo (https://github.com/apache/lucene/tree/main/lucene/demo). The above error (and similar ones) happened always when the Lucene demo was open during "Find Usages" of certain methods of the main project. "Find Usages" worked fine always when the Lucene demo got closed. Note that there are no dependencies from or to the Lucene demo. It is fully reproducible with NB 21 and 22rc1 and multiple iterations opening and closing again.

As I guess that NetBeans is using Lucene during "Find Usages" as well, I could imagine that things may get messed up by different class versions in the class path?! However, this shouldn't normally happen and the errors seem javac-related too.

Anyway, as I got a workaround now and this is a very special case, up to you if you want to close this issue or investigate further. I hope that this ticket helps other persons running into the Lucene issue as well.

If it's simply about having a dependency to Lucene in the class path though, we will run into the same issue soon again, as we are including Lucene into our project (but I can open a new ticket then too).

@mbien mbien added Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) nb-javac Run nb-javac integration tests labels Apr 26, 2024
@mbien
Copy link
Member

mbien commented Apr 26, 2024

thanks for testing with the release candidate.

As I guess that NetBeans is using Lucene during "Find Usages" as well

right, opened projects are added to the "context" so that you can navigate to them if they are a dependency (instead of landing in jars/sources of the jars). If its not a dependency however, it should not affect anything though. So this might be a clue (unless its a race condition again and project count is affecting the timing).

@neilcsmith-net
Copy link
Member

I have a feeling it's to do with the JPMS / module-info usage in the demo. Try changing the scope of your search to not be the default all open projects. Does this help? Also try deleting the cache folder and letting it regenerate.

@herkrath
Copy link
Contributor Author

changing the scope of your search to not be the default all open projects. Does this help?

Yes, no exception. But I would call this a workaround.

try deleting the cache folder and letting it regenerate.

Well, I have to do so like once a week due to other issues, and it also started to happen with 22rc1 immediately, right after the cache got rebuilt too. So no, this doesn't help.

I have a feeling it's to do with the JPMS / module-info usage in the demo.

You seem to be very right. After I have renamed module-info.java to module-info.off, rebuilt the demo and rebuilt the NB cache, the error doesn't occur anymore. Why do you think so? Just because of module-info or Lucene being inside module-info?

@neilcsmith-net
Copy link
Member

I'm pretty sure that Lucene involvement is a red herring. I'm seeing this and related issues with module based projects without that involved.

That it happens directly after opening 22rc1 doesn't surprise me. It's like the initial cache is getting polluted somewhere. I have a feeling that project opening order may have something to do with it. Does a run with a clean cache and no projects work if you open in the order they are depended on?

@herkrath
Copy link
Contributor Author

You are right, Lucene involvement is a red herring. I created a most simple JPMS project (and had the Lucene demo closed all the time). What happened is (in NB 21):

  1. After I created and built it, the same independent "Find Usages" operation gave java.lang.AssertionError: Method parameter without PARAMETER flag once, again from com.sun.tools.javac.... Further "Find Usages" operations on the same method were working fine.
  2. After I have recreated the NB cache, the same "Find Usages" operation was always giving that StackOverflowError when the JPMS project was open, while working fine when it was closed.
    Interestingly, I got the StackOverflowError with NB 21 now. Saw it only with NB 22 before.

Now, how shall we proceed? Shall I try to replicate the issue with simple projects only, such that I can post them here? Or is there a similar issue ticket already?

For sure this is no NB 22 regression.

@PavelTurk PavelTurk mentioned this issue May 3, 2024
Closed
@mbien mbien removed the needs:triage Requires attention from one of the committers label May 23, 2024
@mbien
Copy link
Member

mbien commented May 23, 2024

Now, how shall we proceed? Shall I try to replicate the issue with simple projects only, such that I can post them here? Or is there a similar issue ticket already?

@herkrath I took a look and I don't think there is a similar ticket involving stack overflow. If you can create a small reproducer - I am sure it would help, however it likely won't be easy to come up with one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) kind:bug Bug report or fix nb-javac Run nb-javac integration tests
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mbien @neilcsmith-net @herkrath