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

Netbeans 22 does not load a 8.9 gradle wrapper in project. Infinite loop. #7606

Closed
patton73 opened this issue Jul 24, 2024 · 23 comments · Fixed by #7721
Closed

Netbeans 22 does not load a 8.9 gradle wrapper in project. Infinite loop. #7606

patton73 opened this issue Jul 24, 2024 · 23 comments · Fixed by #7721
Assignees
@lkishalmi @sdedic
Labels
Gradle [ci] enable "build tools" tests kind:bug Bug report or fix
Milestone
NB23

Comments

@patton73
Copy link

Apache NetBeans version

Apache NetBeans 22

What happened

If you have a project with a gradle wrapper 8.9. Netbeans 22 cannot load it. It just starts an infinite loop but does not load anithing.

Language / Project Type / NetBeans Component

No response

How to reproduce

Just make a project with a gradle 8.9 wrapper in it.

Did this work correctly in an earlier version?

No / Don't know

Operating System

Linux Ubuntu 24.04 LTS

JDK

Jdk 17.0.11

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

No response

Are you willing to submit a pull request?

No
@patton73 patton73 added kind:bug Bug report or fix needs:triage Requires attention from one of the committers labels Jul 24, 2024
@troizet troizet added the Gradle [ci] enable "build tools" tests label Jul 24, 2024
@lkishalmi
Copy link
Contributor

Can you test that with NetBeans 23-rc1. That has Gradle 8.9 Tooling in it.

@patton73
Copy link
Author

I am going to test it as soon i can. Anyway it seems to me that the option "prefer gradle wrapper" does not work. I expect that if i choose that option the wrpper inside the project should be used to compile it and not the netbeans' built in tool.

@neilcsmith-net
Copy link
Member

@patton73 you misunderstand. The Tooling API is a Gradle library for executing Gradle builds. It will use the wrapper in the project, and is meant to be forwards compatible. Tooling API 8.7 in NB22 should be able to run a Gradle 8.9 build. I wonder if this is a sign of an upstream compatibility issue, or that NetBeans is doing something with the Tooling API that is breaking that forwards compatibility promise? As well as testing 23-rc1, it would probably be good to understand what is breaking in NB22 so that the issue does not recur.

@patton73
Copy link
Author

Netbeans 22 just does not load the project and it goes on loading forever. No log, no error, nothing to see.

@neilcsmith-net
Copy link
Member

Sure, but a stack dump or similar (eg. jstack) may show what it's stuck in.

@mbien mbien added the pending-response Awaiting further information to be supplied label Aug 4, 2024
@patton73
Copy link
Author

patton73 commented Aug 28, 2024 •
edited
Loading

I tested also the netbeans daily build. And it hangs as well with gradle wrapper.
You have as a test project that hangs, this one: https://github.com/Rebirth-Project/version-comparator
No way to load this project with netbeans 22 and netbeans 23 daily build.

update: same problem with Gradle version 8.10.

@neilcsmith-net neilcsmith-net added this to the NB23 milestone Aug 28, 2024
@neilcsmith-net
Copy link
Member

What else have you tried with? Have you compared to a basic project from Gradle init? Is it all projects affected? Did you import settings when trying NB23 rc?

@patton73
Copy link
Author

What else have you tried with? Have you compared to a basic project from Gradle init? Is it all projects affected? Did you import settings when trying NB23 rc?

The project i linked is a completely IDE free gradle project (you can compile it by command line). Yes I imported old Netbeans 22 settings. I try also to avoid importing old settings to see if it loads without entering the infinite loop.

@patton73
Copy link
Author

Update: even if i do not import netbeans 22 setting the daily build hangs in an infinite loop.

@neilcsmith-net
Copy link
Member

But does it apply to a Gradle project created using gradle init or other projects? I'm still unclear whether it's specific to that project?

@patton73
Copy link
Author

patton73 commented Aug 29, 2024 •
edited
Loading

update: a completely empty project created with "gradle init" with version 8.10 (even without build.gradle since it does not create it) loads. But this does not resolve the problem. I have many projects that i upgraded to gradle 8.9 and 8.10 and they do not load in netbeans 22 and newer. And unfortunately the IDE does not print any error. It just tries to load the project in an infinite loop.

@neilcsmith-net
Copy link
Member

So, do they have any configuration in common? Does removing some / all of the .gradle directory help?

@sdedic
Copy link
Member

sdedic commented Aug 29, 2024

@patton73 could you try to trim down some of the failing projects to a minimal sample (no sources are needed actually, just the build files and dir structure) and attach it ?

@sdedic
Copy link
Member

sdedic commented Aug 30, 2024 •
edited
Loading

OK, the culprit is now known, reproduced on https://github.com/Rebirth-Project/version-comparator. The net.researchgate.release plugin prompts on the stdin or console for release version; the getter is called as a part of project introspection, as the releaseVersion is a valid and readable task property. Sadly the helper method is not private which makes it a public object property in groovy.

Here's the relevant part of stacktrace from the gradle daemon:

"Daemon worker" #31 prio=5 os_prio=0 cpu=4670,32ms elapsed=215,31s tid=0x00007f3784008770 nid=0x5fb5e in Object.wait()  [0x00007f37e8cce000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait([email protected]/Native Method)
        - waiting on <0x00000000e1060b38> (a java.lang.Object)
        at java.lang.Object.wait([email protected]/Object.java:338)
        at org.gradle.internal.daemon.clientinput.StdInStream.waitForContent(StdInStream.java:77)
        at org.gradle.internal.daemon.clientinput.StdInStream.read(StdInStream.java:57)
        - locked <0x00000000e1060b38> (a java.lang.Object)
        at sun.nio.cs.StreamDecoder.readBytes([email protected]/StreamDecoder.java:270)
        at sun.nio.cs.StreamDecoder.implRead([email protected]/StreamDecoder.java:313)
        at sun.nio.cs.StreamDecoder.read([email protected]/StreamDecoder.java:188)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read([email protected]/InputStreamReader.java:177)
        at java.io.BufferedReader.fill([email protected]/BufferedReader.java:162)
        at java.io.BufferedReader.readLine([email protected]/BufferedReader.java:329)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine([email protected]/BufferedReader.java:396)
        at java_io_BufferedReader$readLine.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
        at net.researchgate.release.PluginHelper.readLine(PluginHelper.groovy:183)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0([email protected]/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke([email protected]/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke([email protected]/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke([email protected]/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:149)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy:149)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0([email protected]/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke([email protected]/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke([email protected]/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke([email protected]/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1942)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3815)

I've tried quick patches like giving the gradle's BuildAction an empty (byte[0]) InputStream or even a closed Inputstream, but that did not seem to make any difference (surprisingly). I need to try another magic or - at the worst - make an exclusion for this class:property.

@sdedic sdedic removed the needs:triage Requires attention from one of the committers label Aug 30, 2024
@patton73
Copy link
Author

Strarting from this project : https://github.com/Rebirth-Project/version-comparator

update: cleaning the project and removing .gradle and netbeans cache does nothing.
update2: cleaning the project and removing .gradle and netbeans cache and removing sources leaving only default directories (src/main/java with inside the file module-info.java) loads the project.

The behaviour is absolutely random.

And this does not happen till gradle 8.8 wrapper. Only with gradle 8.9 and newer.

@patton73
Copy link
Author

OK, the culprit is now known, reproduced on https://github.com/Rebirth-Project/version-comparator. The net.researchgate.release plugin prompts on the stdin or console for release version; the getter is called as a part of project introspection, as the releaseVersion is a valid and readable task property. Sadly the helper method is not private which makes it a public object property in groovy.

Here's the relevant part of stacktrace from the gradle daemon:

"Daemon worker" #31 prio=5 os_prio=0 cpu=4670,32ms elapsed=215,31s tid=0x00007f3784008770 nid=0x5fb5e in Object.wait()  [0x00007f37e8cce000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait([email protected]/Native Method)
        - waiting on <0x00000000e1060b38> (a java.lang.Object)
        at java.lang.Object.wait([email protected]/Object.java:338)
        at org.gradle.internal.daemon.clientinput.StdInStream.waitForContent(StdInStream.java:77)
        at org.gradle.internal.daemon.clientinput.StdInStream.read(StdInStream.java:57)
        - locked <0x00000000e1060b38> (a java.lang.Object)
        at sun.nio.cs.StreamDecoder.readBytes([email protected]/StreamDecoder.java:270)
        at sun.nio.cs.StreamDecoder.implRead([email protected]/StreamDecoder.java:313)
        at sun.nio.cs.StreamDecoder.read([email protected]/StreamDecoder.java:188)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read([email protected]/InputStreamReader.java:177)
        at java.io.BufferedReader.fill([email protected]/BufferedReader.java:162)
        at java.io.BufferedReader.readLine([email protected]/BufferedReader.java:329)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine([email protected]/BufferedReader.java:396)
        at java_io_BufferedReader$readLine.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
        at net.researchgate.release.PluginHelper.readLine(PluginHelper.groovy:183)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0([email protected]/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke([email protected]/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke([email protected]/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke([email protected]/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:149)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy:149)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0([email protected]/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke([email protected]/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke([email protected]/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke([email protected]/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1942)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3815)

I've tried quick patches like giving the gradle's BuildAction an empty (byte[0]) InputStream or even a closed Inputstream, but that did not seem to make any difference (surprisingly). I need to try another magic or - at the worst - make an exclusion for this class:property.

You are saying that the "release" task is called automatically even if you do not call the task? Since that is the task that prompts for input. And this does not happen if you compile by command line.

sdedic added a commit to sdedic/incubator-netbeans that referenced this issue Sep 2, 2024
@sdedic
apache#7606: Supply empty stdin, process daemon's stdout to avoid lockup
458ce18
sdedic added a commit to sdedic/incubator-netbeans that referenced this issue Sep 2, 2024
@sdedic
apache#7606: Supply empty stdin, process daemon's stdout to avoid lockup
71d7936
@sdedic sdedic mentioned this issue Sep 2, 2024
Merged
@mbien mbien removed the pending-response Awaiting further information to be supplied label Sep 3, 2024
sdedic added a commit to sdedic/incubator-netbeans that referenced this issue Sep 4, 2024
@sdedic
apache#7606: Supply empty stdin, process daemon's stdout to avoid lockup
220f197
@sdedic
Copy link
Member

sdedic commented Sep 5, 2024 •
edited
Loading

You are saying that the "release" task is called automatically even if you do not call the task? Since that is the task that prompts for input. And this does not happen if you compile by command line.

No. The task is not run. But NetBeans inspect all configured tasks and extensions for their properties. This task's field is (I guess) accidentally public (the author perhaps didn't care about default groovy visibility) making it formally a property - and mere reading of the property value results in an interactive prompt.

@mbien
Copy link
Member

mbien commented Sep 5, 2024

Update: even if i do not import netbeans 22 setting the daily build hangs in an infinite loop.

@patton73 can you clarify what you mean by infinite loop? Does NetBeans keep doing something in a loop and it never completes, or does it mean that it gets stuck and the PC is idling from that point on.

@patton73
Copy link
Author

patton73 commented Sep 6, 2024 •
edited
Loading

Update: even if i do not import netbeans 22 setting the daily build hangs in an infinite loop.

@patton73 can you clarify what you mean by infinite loop? Does NetBeans keep doing something in a loop and it never completes, or does it mean that it gets stuck and the PC is idling from that point on.

NetBeans keep doing something in a loop and it never completes. In particular it never loads the current project. it never finishes to load it. But it does not hang. You can continue working on other projects.

@sdedic
Copy link
Member

sdedic commented Sep 6, 2024 •
edited
Loading

@patton73 we are arguing about the wording loop, which indicates something is being done repeatedly, over and over. Like displaying again and again an error message about an unloadable project, or finishing the load and starting the project load again etc. During my investigation I didn't observe repeated actions, but just one pending and never finished action (project load).

So the question is whether you are sure about repeating (loop) - and the issue should be analyzed more to reproduce the "loop", or the report was simply inaccurate and we can assume the issue is fixed. With the PR applied I am able to open the test project without problems.

@patton73
Copy link
Author

patton73 commented Sep 6, 2024

Ok to be precise that is not a loop but a "pending" loading action that never finish. I called it a loop because in the status bar (bottom-right) the action never ends and the UI always shows the loading running action. So ok that is not a loop.

ebarboni added a commit that referenced this issue Sep 6, 2024
@ebarboni
Merge pull request #7721 from sdedic/gradle/tooling-blocked-stdin
fceae80 
#7606: process daemon's stdout to avoid lockup
@mbien
Copy link
Member

mbien commented Sep 6, 2024

@patton73 thanks for clarifying! all good. Thats what we saw too.

@patton73
Copy link
Author

patton73 commented Sep 9, 2024

I tested the new daily build. Now it works. I would close this bug.
Thanks a lot for your help.

@mbien mbien closed this as completed Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lkishalmi lkishalmi

@sdedic sdedic

Labels
Gradle [ci] enable "build tools" tests kind:bug Bug report or fix
Projects
None yet
Milestone
NB23
Development

Successfully merging a pull request may close this issue.

#7606: process daemon's stdout to avoid lockup sdedic/incubator-netbeans
6 participants
@mbien @lkishalmi @neilcsmith-net @troizet @patton73 @sdedic