-
Notifications
You must be signed in to change notification settings - Fork 312
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
Stuck at JNI boundary? #5782
Comments
Are you able to share the source code to the project? Also, do you get more details when running with |
Proprietary, sorry. I'll see about running with |
Ran using:
No additional processing information was written to the console. Perhaps the first task in tracking this down would be to add more logging into the system around the resolver/analyzer?
As a work around you could put the analyzer thread on a timeout and if it blocks for more than 5 minutes (configurable, of course), throw an exception and move on. |
That's probably because you use both |
Hangs here:
|
We are having the same issue, but without any JNI dependency whatsoever. Unfortunately the |
Are you maybe in a position to debug this yourself? Eventually, adding more |
If you could give me some more instructions about where to put additional log statements, I could do that. I tried adding a log in the
|
Do you see the "Gradle may use a maximum of XXXX MiB of memory" message somewhere in the log output? Alternatively, can you share the project you're analyzing? |
Unfortunately I cannot share. But I can provide the relevant logs (even though I have to cut any company information, replaced with
It is an Android project. As you can see we have three Thanks for taking a look and helping! |
I don't think so. Could you maybe try to minimize your project to that it still reproduces the issue, but does not contain any private information, and then share it? Or alternatively, try to modify our existing Android test project so that it reproduces the issue? |
Unfortunately I cannot strip down the project to publish it (too much effort), so I took your example and adapted it step by step. I found three dependencies responsible for ORT hanging at the |
I just tried an older version for Hilt: going back from |
I can reproduce the issue, that's great, thanks for that! However, I also see it hanging with Hilt 2.43.2. |
Changing the lines ort/analyzer/src/main/kotlin/managers/Gradle.kt Lines 204 to 205 in 63b2b2d
to read
yields on-the-fly output that shows that analysis is actually not hanging, but extremely slow, and this message shows up for every Gradle configuration:
|
Oh wow, thanks for revealing what's going on here! Well that's somehow annoying since I left ORT running for our Project for about 7 hours hanging at this message and then finally canceled the task :D And the machine was quite powerful. So it seems we are stuck here or have to live with the fact that it could take hours to run ORT or do you have any idea how to tackle this? I must admit, I am not that familiar with Gradle config, etc. |
Here's a stacktrace:
So it seems ORT's way of resolving dependencies at Gradle configuration time is inherently incompatible with the Android plugin's check not to do that. We have several ideas how to change the Gradle analysis in the context of another issue, but until then I don't have an idea for a work-around right now. All in all, your issue @mpbecker more looks like #5622 than this issue, as @DaveJarvis does not seem to be using an Android project. |
Alright! Big shout outs for helping on such short notice. Really appreciate it, thanks! |
Correct, we're not using Android. And it could be that ORT isn't hanging but merely taking a long time to run. In either case, having tonnes of information about what's going on would be quite helpful. Information such as:
We're running ORT through a rather picky firewall, so it could be getting stuck on downloads. |
FYI, @DaveJarvis, some more progress info has just been added with #5964. |
@DaveJarvis, do you happen to know whether there's a BOM artifact in your dependency tree? If so, #5964 might fix your issue, too. |
Thanks for the update. I don't know whether there was a BOM artifact. |
@DaveJarvis could you give the new GradleInspector a try? |
Sorry, I won't be back this way. We now hand-maintain our XML files that contain the licensing information. ORT was instrumental in getting us 80% of the way there. |
Thanks for reporting back anyway @DaveJarvis, and good to hear that ORT was at least of some help to you! |
I just verified that the current version of ORT's Gradle analyzer also does not hang anymore for @mpbecker's case, see the analyzer-result. So I'm closing this as the issue is not reproducible anymore. |
Background
A Java application has ties to a C/C++ program via the JNI.
Problem
ORT did not complete processing the build.gradle file, yet gave no indication as to an error.
Expected
ORT shows an error to indicate that it encountered an issue resolving licensing information or the hanging loop prints a progress report to the user to indicate what's happening.
Actual
ORT hangs. After 30 minutes, no progress made, I stopped ORT.
Work around
conformance/build.gradle
.This allowed ORT to proceed without hanging. (At least until the troublesome JNI project was referenced from another project, which resulted in another hang, but it appears to be the same issue.)
The text was updated successfully, but these errors were encountered: