StackOverflowError on resolving static import

[slytechs-repos]

Started having this issue right after my ubuntu 22.04.2 LTS system did a software update.

Having a single editor open, is fine, but the moment a second editor is open on any file, it immediately starts gobling up memory (as per HEAP monitor in the window) until it hits 2048MB and eventually throws an OOM exception.

I have tried the following:

1) Reinstalled a new instance of Eclipse (for Java) 2023-3. 2) Removed .metadata directory from workspace root and started from scratch 3) Started eclipse with -clean option and from a terminal window to see any additional output

Nothing has worked, even if I restart the workbench but with 2 editors open, it immediatly starts consuming all memory. Obviously a runaway recursive loop.

Thank you for your help. mark....

---- logs and info ----

Starship:~/eclipse-workspace/jnet> lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy

Starship:~/eclipse-workspace/jnet> java -version java version "19" 2022-09-20 Java(TM) SE Runtime Environment (build 19+36-2238) Java HotSpot(TM) 64-Bit Server VM (build 19+36-2238, mixed mode, sharing)

Starship:~/eclipse/java-2023-03/eclipse> more eclipse.ini -startup plugins/org.ecli .log.zip pse.equinox.launcher_1.6.400.v20210924-0641.jar --launcher.library /home/mark/.p2/pool/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.700.v20221108-1024 -product org.eclipse.epp.package.java.product -showsplash /home/mark/.p2/pool/plugins/org.eclipse.epp.package.common_4.27.0.20230309-1200 --launcher.defaultAction openFile --launcher.appendVmargs -vm /usr/lib/jvm/jdk-19/bin -vmargs -Dosgi.requiredJavaVersion=17 -Dosgi.instance.area.default=@user.home/eclipse-workspace -Dosgi.dataAreaRequiresExplicitInit=true -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true -Dsun.java.command=Eclipse -Xms256m -Xmx2048m -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM Eclipse-2022-04-workspace-metadata.log

-Declipse.p2.max.threads=10 -Doomph.update.url=https://download.eclipse.org/oomph/updates/milestone/latest -Doomph.redirection.index.redirection=index:/->http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/

!SESSION 2023-05-22 11:19:48.156 ----------------------------------------------- eclipse.buildId=4.27.0.20230309-1200 java.version=19 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product -clean -consolelog

Exception in thread "Text Viewer Hover Presenter" java.lang.StackOverflowError at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:813) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:742) at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:188) at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:542) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.fromSplitPackageOrOracle(LookupEnvironment.java:427) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.lambda$1(LookupEnvironment.java:300) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForTypeFromModules(LookupEnvironment.java:394) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:299) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588) at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:141) at org.eclipse.jdt.internal.codeassist.SelectionEngine.accept(SelectionEngine.java:375) at org.ecli pse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588) at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:141) at org.eclipse.jdt.internal.codeassist.SelectionEngine.accept(SelectionEngine.java:375) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588) at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:141) at org.eclipse.jdt.internal.codeassist.SelectionEngine.accept(SelectionEngine.java:375) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)

Eclipse-2022-04-workspace-metadata.log

[slytechs-repos]

I reinstalled ubuntu and bumped it to

starship:~/eclipse/java-2023-03/eclipse> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 23.04
Release:    23.04
Codename:   lunar

Reinstalled Elicpse 2023-03 again and started a new work-space. Checkout a github project and the moment I open up multiple files, start getting OOM errors and stack overflows.

I can't be the only one having this issue, something seriously wrong with the latest ubuntu compatibility and elicpse.

[iloveeclipse]

I can't be the only one having this issue

Sure you can :)

I use latest nightly Eclipse builds daily for years now, and never saw such issue. So something with your setup is flawed and we can only understand it if you shares exactly what you do.

To reproduce your issue we don't need ubuntu, but: 1) Simple project that you use with all settings 2) Exact steps to reproduce : which files do you open, in which editor etc.

What you can also do is : try to use plain SDK, latest build from https://download.eclipse.org/eclipse/downloads/ with the new workspace. No oomph, no old settings, default eclipse.ini.

I'm pretty sure it will work. From there on, try step by step understand what in the old setup makes you unhappy.

[slytechs-repos]

You don't understand, I did that. Reinstalled ubuntu and Elicpse, used defaults, new empty workspace. Clone my git repo into it and open up 3 files and off it goes with exceptions and OOM.

Here is the git clone: git@github.com:slytechs-repos/core-protocols.git

Open up 3 files, and then drag to each new window/section and it does it everytime.

Even opening up a package-info.java file will do the trick.

[iloveeclipse]

You don't understand, I did that.

Sure I understand and sure you did not what I've asked you to do.

Open up 3 files,

which files exactly?

and then drag to each new window/section

Sorry, what does that mean? To which window/section? Do you mean one has to open 3 different windows? And if you don't drag, no errors?

Would you please provide exact steps? May be a screenshot or even a video?

[iloveeclipse]

The log file contains lot of various errors, some saying about OOM.

Can you please change -Xmx2048m to -Xmx8g in your eclipse.ini to see if it is not a problem with too small heap size?

[slytechs-repos]

Sorry, let me back up:

I use latest nightly Eclipse builds daily for years now, and never saw such issue. So something with your setup is flawed and we can only understand it if you shares exactly what you do.

I understand, I have been using eclipse for 20 years myself, and never had this kind of problem. I'm able to resolve, lost/corrupt config issues with eclipse, natures, etc...

Using JDK-19 with --enable-preview switch as my libraries rely on Foreign Function Features (in preview).

Simple project that you use with all settings Try cloning git@github.com:slytechs-repos/core-protocols.git

Exact steps to reproduce : which files do you open, in which editor etc. What you can also do is : try to use plain SDK, latest build from https://download.eclipse.org/eclipse/downloads/ with the new workspace. Downloaded and installed 2023-03 (4.27), the latest

No oomph, no old settings, default eclipse.ini. Didn't touch the .ini file.

I'm pretty sure it will work. From there on, try step by step understand what in the old setup makes you unhappy.

I'm doing everything from scratch on a single project. I increased to 8g and it still goes to OOM. If you look at the log file attached to the 1st post, its a recursive infinite loop. I had some C structure in the javadoc comments, I though maybe the comment parser had trouble with that, but it still does it with or without the comment.

[slytechs-repos]

Here is the screen shot with the -Xmx8g setting.

[slytechs-repos]

Its a doozy. Everything worked fine until the ubuntu upgrade yesterday. I wonder if there is a GTK 3 issue with the latest (very recent) ubuntu updates or something obscure like that.

Here is the log file output:

    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:345)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
    at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209)
...

[iloveeclipse]

Can you please attach error log file from the latest SDK build?

The stack overflow is from JDT and in theory can't be related to GTK version change. Does the problem also appear if you don't place editors next to esch other?

Did the Java version changed during Ubuntu update?

[slytechs-repos]

Here you go: Eclipse-2023-03-r4.27.log

[iloveeclipse]

Here you go: Eclipse-2023-03-r4.27.log

This is not latest 4.28 build.

[slytechs-repos]

The stack overflow is from JDT and in theory can't be related to GTK version change. Does the problem also appear if you don't place editors next to esch other?

The reason I mentioned the GTK is because initially (before reinsalling ubuntu with 20.3) I saw a few errors from eclipse about GTK lock errors. This is when I started the ./eclipse from the command line to see if there were any other errors. After a reboot and since the new install, I haven't seen those.

Yes it does. I normally run in multi-monitor mode and spread multiple editors in multiple panes across the 2 monitors. However, just having 3 java editors open in a single pane is enough. If I switch between them (by clicking the tab) enough it eventually goes into OOM spin.

[slytechs-repos]

Oops, sorry. I just downloaded the latest and ran it over the existing workspace:

Eclipse SDK
Version: 2023-06 (4.28)
Build id: I20230517-1800
OS: Linux, v.6.2.0-20-generic, x86_64 / gtk 3.24.37
Java vendor: Oracle Corporation
Java runtime version: 19.0.2+7-44
Java version: 19.0.2

At least I'm getting a more concise error dialog:

[iloveeclipse]

Can you please attach error log file from the latest SDK build?

[iloveeclipse]

Did the Java version changed during Ubuntu update?

[slytechs-repos]

Here you go. Looks like its reporting some git-provider issue. I'll try and configure that right now.

Eclipse-2023-06-4.28.log

[slytechs-repos]

Did the Java version changed during Ubuntu update?

Initially it did change the default java. I had to use update-alternatives to manually reset the java default /usr/bin/java and javac configs back to jdk-19.

[slytechs-repos]

I suppose, it won't hurt to try to run it with openjdk-19. I had been using Oracle's JDK-19 package for a few months just prior and before that openjdk-17/18/19.

[slytechs-repos]

Running now:

Eclipse SDK
Version: 2023-06 (4.28)
Build id: I20230517-1800
OS: Linux, v.6.2.0-20-generic, x86_64 / gtk 3.24.37
Java vendor: Private Build
Java runtime version: 19.0.2+7-Ubuntu-0ubuntu4
Java version: 19.0.2

And the /usr/bin/java

starship:~/eclipse/eclipse-SDK-4.28M3-linux-gtk-x86_64/eclipse> java -version
openjdk version "19.0.2" 2023-01-17
OpenJDK Runtime Environment (build 19.0.2+7-Ubuntu-0ubuntu4)
OpenJDK 64-Bit Server VM (build 19.0.2+7-Ubuntu-0ubuntu4, mixed mode, sharing)

Getting the same error. When I click show error in the dialog:

[iloveeclipse]

Stack overflow is caused by JDT, no doubt, I can check it tomorrow if it is reproducible for me with your project. Typically that kind of errors doesn't have relationship to OS updates, it is really interesting what was the trigger. What JDT surely affects is the configured JDK for the project. So can you change back to the version used before OS update?

[slytechs-repos]

I was using the Oracle's JDK-19 (/usr/lib/jvm/jdk-19). I am going to blow away the worspace again and clone from the beginning. Making sure that I don't get those git config errors in the log.

I appreciate you looking into this!

[slytechs-repos]

Ok, I narrowed it down. In my repo git@github.com:slytechs-repos/core-protocols.git I have several branches.

The JDT errors are related to one specific branch. Some code or comment I added that it doesn't like. If you clone that repo and then switch between 'main' and 'develop' branches, you can do that as many times as you like and it behaves perfectly normal (memory usage doesn't budge.) The 2 branches have many differences in code.

The moment you switch to feature-meta-resources-quick-enhancement, which is the latest branch I was working on when the anomaly began, you get the error immediately. You switch back to main or develop before it runs out of memory and it goes back to normal. Very repeatable, at least for me. You do not even have to have any files open to trigger this, as you said its coming from the JDT compiler component not related to the UI.

So with that in mind.

Here is the last thing that I changed, that I initially thought might be the cause. I added the C-Style comment int pre tag and a couple of temporary constants right at the top, caught in this screen capture. I was getting ready to change that structure and was working on different scenarios.

I'll go back to different versions within that branch to see if I can pin it down a bit more.

[slytechs-repos]

Looks like it was down to a single file: com.slytechs.protocol.pack.PackId in the repo. I restored a previous version of the file and its stable. It must be that C-style comment it doesn't like and can't handle. I can't believe that actual valid java constants would cause this.

What a weird problem and a coincidence with the system update that send me looking in the wrong direction.

Let me know if you want to work on this to nail down exactly why it gets triggered, otherwise I'm back in working order on my end.

BTW I had to go back to Eclipse 2023-03 as the latest version won't let me enable JDK 19 preview features (even when using system JDK-19 library under build path). It seems to be hard coded for JDK 20 and won't budge.

[iloveeclipse]

Let me know if you want to work on this to nail down exactly why it gets triggered

It would be great if you could reduce the error to a standalone reproducible example project with one or two files showing the problem. Ideally without any 3rd party libraries/maven etc, so it could be even used as a template for the test case.

[jukzi]

The stacktrace looks like the endless recursion it was introduced with #269 "Fix type hierarchy for cyclic static imports" at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)

[trancexpress]

The stacktrace looks like the endless recursion it was introduced with #269 "Fix type hierarchy for cyclic static imports" at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)

Thanks @jukzi ! I'll take a look today.

[trancexpress]

@slytechs-repos please provide the actual Eclipse project, including compiler settings (will be in the .settings/ folder of the archived project you attach). I got the contents to compile (head at https://github.com/slytechs-repos/core-protocols/commit/6e49be4f2ea591f69164ab174db84582e8f9721e), but I cannot reproduce the stack overflow (tried with latest integration build and with 4.27 release). Maybe there are some compiler settings that I need, but don't have.

[slytechs-repos]

I will try and narrow it down for you. Now that I know what I'm looking for, and I now realize that I've ran into this before, many times, but never to point where entire project was unusable as with this issue.

As to compiler settings, the only thing I really use is the --enable-preview option and do use enhanced switch, no pattern matching yet. I do use static imports as the library uses 100s of constants that are placed in files dedicated class files for constants to keep things organized and easy to find.

I have "Run configuration" tweaked quiet a bit for certain example and test cases, but that should have anything to do with JDT:

--enable-native-access=org.jnetpcap,com.slytechs.protocol,com.slytechs.jnetpcap.example,com.slytechs.jnetpcap.pro
-ea
--enable-preview

As I stated, I can't use the latest Eclipse version because it seems to be hard coded for JDK 20 preview features, unless there is a way to get around that enable it for JDK-19, I have to stay with 2023-03 version. Although in a few weeks I will be moving on from JDK-19 to JDK-20 after this next release and then I can use the latest Elicpse.

[slytechs-repos]

Ohh here is a clue, in my previous reply where I posted a screenshot of the history compare

https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1081#issuecomment-1560142359

The java constants, which I didn't think had anything to do with the issue, those constants declaration are using references to static imports, specifically PACK_ID_CORE which is com.slytechs.protocol.pack.ProtocolPackTable.PACK_ID_CORE imported statically.

Now to figure out what combination of code triggered that, as it works fine in many other areas of the code referencing the same constant statically. Here is another very constant filled class com.slytechs.protocol.pack.core.constants.CoreConstants. I would think if there were any static import issues, it would step from this file, as this is used through out my code and several different Java modules.

[trancexpress]

I will try and narrow it down for you. Now that I know what I'm looking for, and I now realize that I've ran into this before, many times, but never to point where entire project was unusable as with this issue.

Is there something that prevents you from archiving the project and attaching it to the ticket? That should be enough, I hope (unless maybe some compile settings are coming from the workspace, but you said you tried in a new workspace too).

Right-click on the project -> Export -> General -> Archive File

[slytechs-repos]

Easier said than done as Elicpse crashes and burns when it runs out of memory before you can complete the export operation :)

Working on it.

[slytechs-repos]

Ok, got it. Here is the archive of the Export -> General -> Archive File of the self contained project.

Open up 3 files in the com.slytechs.protocol.pack java package from the src/java/main tree and what the "heap counter" (Windows -> General -> Show Heap Status) go nuts. I'm using -Xms8g setting, which buys me more time to analyze before OOM exception happens. Also closing the project, stops that runaway memory, so that is one way to "reset" things and try something else. It will crash just on recompile (Project -> clean) option without anything open. And so on.

Let's see if this works.

sly-techs-eclipse-crash-issue1081.zip

[trancexpress]

I still see the stack overflow after reverting the changes for https://github.com/eclipse-jdt/eclipse.jdt.core/issues/269. This makes sense, since the fix only sorts which imports are resolved first. It doesn't change how the actual resolving is done.

The loop of static imports is simple, I'm not sure why I don't run into the stack overflow in other examples.

[trancexpress]

The stack overflow seems quite old, I can reproduce with:

Eclipse SDK
Version: 2019-09 (4.13)
Build id: I20190901-1800

Note that the project doesn't actually compile since such versions don't support Java 19 source/target/release. But a similar stack overflow is seen (same methods, slightly different lines since the code was different). It crashes the background indexer on Eclipse start.

Cannot reproduce with:

Eclipse SDK
Version: 2019-09 (4.13)
Build id: I20190701-1805

I have no other version in-between. Its also hard to tell if this is an actual regression between the 2. But I'll try to bisect, maybe that helps somewhat.

The loop itself doesn't seem simple to fix, since there are different objects on the stack trace (so a simple "are we looking for imports of X already" won't help).

First commit I see the stack overflow with is: 1fbf13c28311e9090a4ae402b14adbc440f874ec

Unfortunately this is a massive rework, so not very helpful to know the commit.

[jukzi]

one could add a Set of objects we are already searching for

[trancexpress]

one could add a Set of objects we are already searching for

The CompilationUnitScope objects on the stack trace are different objects.

[jukzi]

Instead of using the stack one can use a threadlocal set. Or is the problem to find a suitable key with hashCode and equals?

[trancexpress]

Reduced reproduction snippet: TestGH1081_reduced.zip

package com.slytechs.protocol.pack;

import static com.slytechs.protocol.pack.ProtocolPackTable.*;

public interface PackId {

}

package com.slytechs.protocol.pack;

import static com.slytechs.protocol.pack.PackId.*;

public enum ProtocolPackTable implements PackId {

}

package com.slytechs.protocol.pack.core.constants;

import static com.slytechs.protocol.pack.ProtocolPackTable.*;

import com.slytechs.protocol.pack.PackId;
import com.slytechs.protocol.pack.ProtocolPackTable;

public enum CoreId implements PackId {

    /** The payload. */
    PACK(),

    /** The payload. */
    PAYLOAD(Payload::new)
    ;

}

module com.slytechs.protocol {

    exports com.slytechs.protocol;
    exports com.slytechs.protocol.pack.core;

}

Rebuild the Java index (Window -> Preferences -> Java -> Rebuild Index) to reproduce the stack overflow.

Weirdly the unbound JRE classpath container also seems to make a difference.

[trancexpress]

A reproducer made from scratch:

TestGH1081.zip

Making the JRE classpath container invalid seems to result in the stack overflow:

https://github.com/eclipse-jdt/eclipse.jdt.core/assets/24752155/a38fa1d1-4cd8-43c8-8c6f-6a8c1f49e141

Maybe this is why it started occurring after an update? The JDK installation changed and the project had an unbound JRE on the classpath?

So far I fail to reproduce the stack overflow with a project that compiles. @slytechs-repos , have you seen the problem with a project that does compile without errors? Maybe there is a better reproducer if so. If not, I'm not sure how we want to add a test for this.

[slytechs-repos]

From my experience, I've ran into the case where I get the error popups just by changing something in the code (which should compile) or comments, and then its really hard to get it stop producing that error popup. I always thought it was more related to parsing the java comments sections, because I use "JAutodoc" with all my projects and also the "Javadoc" eclipse pane which always causes the comments to be parsed in the editor.

Maybe this is why it started occurring after an update? The JDK installation changed and the project had an unbound JRE on the classpath?

As to your other points, JDK container did change to something really low, like JDK 8 after the OS update and I had to reset the linux "alternatives" to point back to correct JDK. I normally do not mess with the eclipse.ini file, as the defaults so far have served me well enough. However, if that was the trigger, I never run anything below JDK-19 nowadays. Seems like the lowest JDK level for OSGI components is JDK-17.

Do you think that rebuilding the java index, would reset it the JDT back to reliable state?

As to other tidbits. I do rely on --enable-preview setting. I also use the /* @formatter:off */ /* @formatter:on */ settings to align things for better readability of the source code. Large constant declarations as this project relies on a lot of constants, that are also part of the public API. Mentioning this in case there is a javadoc comment correlation.

Lastly, the project does have a separate src/test/java directory and the junit test cases do not work unless you add junit library to the 'classpath' not the 'modulepath'. So its a combination of module and class path look ups. Also has separate output directories for module code and test classes. I changed those to point at 'target/classes' and 'target/test-classes' to match the 'maven' bulid output dirs which are used to build as well, but not during development (eclipse builds only) and maven occasionally to make sure everything matches up and syncs up.

Making the JRE classpath container invalid seems to result in the stack overflow:

Curious. I'm not sure how else to reproduce this issue, with a smaller snippet.

[jukzi]

TestGH1081.zip

As soon as i import that existing project into workspace i get uncaught(!) Stack overflow error in Java Indexing

Daemon Thread [Java indexing] (Suspended (uncaught exception StackOverflowError))   
    IndexManager(JobManager).indexerLoop() line: 548    
    0x000000080152db10.run() line: not available    
    Thread.run() line: 833  

!ENTRY org.eclipse.jdt.core 4 4 2023-05-25 07:39:57.725
!MESSAGE Background Indexer Crash Recovery
!STACK 0
java.lang.StackOverflowError
    at org.eclipse.core.internal.filesystem.local.LocalFileNatives.internalGetFileInfoW(Native Method)
    at org.eclipse.core.internal.filesystem.local.LocalFileNatives.fetchFileInfo(LocalFileNatives.java:116)
    at org.eclipse.core.internal.filesystem.local.LocalFileHandler.fetchFileInfo(LocalFileHandler.java:30)
    at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.fetchFileInfo(LocalFileNativesManager.java:87)
    at org.eclipse.core.internal.filesystem.local.LocalFile.fetchInfo(LocalFile.java:161)
    at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:260)
    at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:831)
    at org.eclipse.core.internal.resources.File.getContents(File.java:277)
    at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1208)
    at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1201)
    at org.eclipse.jdt.internal.core.util.ResourceCompilationUnit.getContents(ResourceCompilationUnit.java:54)
    at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13420)
    at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13392)
    at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:11778)
    at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.accept(SourceIndexer.java:130)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:337)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
...
    at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.accept(SourceIndexer.java:132)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:337)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:578)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:289)
    at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:256)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:588)
...
    SourceIndexer.accept(ICompilationUnit, AccessRestriction) line: 132 
    LookupEnvironment.askForType(PackageBinding, char[], ModuleBinding) line: 337   
    SplitPackageBinding(PackageBinding).getTypeOrPackage(char[], ModuleBinding, boolean) line: 276  
    CompilationUnitScope.findImport(char[][], int) line: 578    
    CompilationUnitScope.resolveImports(int, ImportBinding[], int, Predicate<ImportReference>) line: 289    
    CompilationUnitScope.checkAndSetImports() line: 256 
    LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration, boolean) line: 588   
    SourceIndexer.accept(ICompilationUnit, AccessRestriction) line: 132 
    LookupEnvironment.askForType(PackageBinding, char[], ModuleBinding) line: 337   
    SplitPackageBinding(PackageBinding).getTypeOrPackage(char[], ModuleBinding, boolean) line: 276  
    CompilationUnitScope.findImport(char[][], int) line: 578    
    CompilationUnitScope.resolveImports(int, ImportBinding[], int, Predicate<ImportReference>) line: 289    
    CompilationUnitScope.checkAndSetImports() line: 256 
    LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration, boolean) line: 588   
    SourceIndexer.accept(ICompilationUnit, AccessRestriction) line: 132 
    LookupEnvironment.askForType(PackageBinding, char[], ModuleBinding) line: 337   
    SplitPackageBinding(PackageBinding).getTypeOrPackage(char[], ModuleBinding, boolean) line: 276  
    CompilationUnitScope.findImport(char[][], int) line: 578    
    CompilationUnitScope.resolveImports(int, ImportBinding[], int, Predicate<ImportReference>) line: 289    
    CompilationUnitScope.checkAndSetImports() line: 256 
    LookupEnvironment.completeTypeBindings() line: 516  
    SourceIndexer.resolveDocument() line: 171   
    JavaSearchParticipant.resolveDocument(SearchDocument) line: 117 
    IndexManager.indexResolvedDocument(SearchDocument, SearchParticipant, Index, IPath) line: 682   
    IndexManager$2.execute(IProgressMonitor) line: 1296 
    IndexManager(JobManager).indexerLoop() line: 514    
    0x000000080152db10.run() line: not available    
    Thread.run() line: 833  
...

Cannot reproduce with a bound JRE, but can also reproduce when i completely remove JRE from build path