java.nio.channels.OverlappingFileLockException for Jacoco offline #331
Comments
|
@david-wei-wei Quoting JavaDoc for OverlappingFileLockException - "Unchecked exception thrown when an attempt is made to acquire a lock on a region of a file that overlaps a region already locked by the same Java virtual machine". However in case of online instrumentation single JVM should have only single JaCoCo agent, and in case of offline instrumentation agent isn't needed and I suspect that indeed may interfere, so shouldn't be used. So could you please check those conditions? |
|
@Godin Thanks for your quick reply. |
|
It actually looks like there are two JaCoCo agents involved, maybe in two different versions (otherwise JaCoCo would detect this situation). |
|
So what would be interesting is the full command line of the running server process. |
|
@marchof @Godin I have dumped the thread stack. It seems that there are two JVM shutdown hooks in a classloader:PolicyClassLoader and a javaagent:DebugPatchAgent. My test process:
The exception will occur during stopping the server.
command: key logs: |
|
@david-wei-wei As was said earlier - you don't need JaCoCo agent, if you use offline instrumentation. They both register shutdown hook and so interfere. |
|
@Godin I remembered I did't use JaCoCo agent, I only set JaCoCo properties in Java Command: |
|
@david-wei-wei I suspect that |
|
@david-wei-wei Another explanation could be that jar file |
|
@david-wei-wei Any updates on this issue? |
marchof
added
declined: invalid ❌
and removed
feedback pending
|
Hello, I've ran into exact that problem when creating eclipse RCP application, according to jacoco offline instrumentation, jacocoagent.jar should be in class path, since rcp uses own class loaders for different plugins, I had to add jacocoagent.jar both in classpath of junit tests, and in one of RCP module, and got described problem. Agent based instrumentation also not easily possibly for my project, dueto extensive usage of powermock. So I've tried proposed solution with cycle and several attempts to lock file, in my case there were only 1 collision, |
|
@evgen48 could you please provide reproducer? this will greatly increase chances to re-open this ticket and finally make an official fix for it. |
Godin
added
feedback pending
|
@Godin For me the case of @evgen48 is obvious: If you put jacoco into multiple OSGi bundles you get different instances, as every bundle has its own classloader. I would close this ticked as invalid. We might improve error reporting though: If there would be a reliable way to detect that we have more than one JaCoCo runtime in a JVM we could issue a proper error message. |
|
@marchof after careful rereading and your comment indeed case is obvious And now I'm wondering: ok, offline instrumentation is required because of use of PowerMock, but what if it is combined with agent - I don't remember, if in this case it is still required to have |
|
@Godin Either add |
|
FYI: Just stumbled upon this in Quarkus and created an issue there: quarkusio/quarkus#9837 I doubt that Quarkus can/will work around all cases, so any improvement on your side (JaCoCo) is very much appreciated! |
|
@famod Thanks for the detailed analysis on the Quarkus issue! Do you have specific proposals what we can improve in the JaCoCo side in this situation? |
|
@famod Here is the version to for testing: https://ci.appveyor.com/project/JaCoCo/jacoco/builds/33396073/artifacts |
|
@marchof Thanks, that was quick! Will test that later this week. To be fair and transparent, me and my team have just decided to evaluate a possible online solution first: quarkusio/quarkus#9837 (comment) |
|
@marchof I am having a hard time getting the testing version to work properly in a Maven setup (https://github.com/famod/quarkus-issue-9837). as this yields: I guess the dedepencies of the Maven-Plugin are inconsistent (still on 0.8.5)? Sorry for so many questions but I am a bit lost. Thanks! |
|
@marchof ping, thanks! |
yep, quoting https://www.jacoco.org/jacoco/trunk/doc/faq.html :
For the match between you can try either building from @marchof branch: or try to update dependency of after installing artifacts mentioned in #331 (comment)
Don't know what you mean by "it", "regular" and "other", but content of ZIP is described in documentation at https://www.jacoco.org/jacoco/trunk/index.html (
|
|
@Godin Thanks a lot for this very detailed answer!
I was under the impression that there are three Again, thanks for this clarification! I'll try building from the branch and will report back. |
|
|
I must say it is rather disappointing that the fix for this is not included in the recently released 0.8.6. The PR is over 3 months old. |
|
@famod I apologies that this PR did not make it into the release. Please understand this is all spare time work. We prioritized the release because of experimental Java 15 and Java 16 support. Also we didn't want to do a "last minute merge". There will be a release soon, for official Java 15 support, so there is another chance to get this PR in. |
|
@marchof ok, thanks for letting me know. |
|
Just a +1 on merging this and hopefully getting a release soon, since it's also affecting us and we tested with this branch and the fix works. Thanks. |
|
any updates on this? im waiting to be fixed |
|
@marchof I just realized today that there was another release and this still didn't make it. Just to set expectations, will this be merged at some point? Can we help in any way? Thanks. |
|
@xtaixe Here is why we lowered priority of this - in the meantime while we were on Java 16, as far as we can see quarkusio/quarkus#9837 was solved on Quarkus side by quarkusio/quarkus#14311 Isn't it? Or in your case it is not about Quarkus? |
|
@Godin that comment mentions why it wasn't added in Our issue is with using Quarkus, but the Quarkus solution won't work for us cause it only works for a specific type of Quarkus tests (plus not sure if it works for Maven multi module projects). So right now, we are running a patched JaCoCo jar to be able to get coverage properly, so it's going to be a pain to upgrade for every release this is not in... Since this seems to be ready and tested by some people, can it be prioritized now? |
As was already said - we saw resolution of corresponding ticket on Quarkus side, but till now no mention of
maybe I miss something, but don't see any example of this or any mentions of this anywhere on Quarkus side, while IMO this is valuable information - maybe Quarkus developers can already suggest something for your type of tests or do further improvements, or improve documentation/examples by mentioning known limitations. Anyway thank you for sharing/mentioning this at least here now 👍 Also yes sorry that this opportunity and ticket were overlooked in
Yes and thank you for the reminder, explanations and testing. |
|
Cool. Thanks! Sorry, I see now I didn't understand your first comment about priority properly and you are right it should have been mentioned the Quarkus solution has some caveats... In case it helps or just FYI the Quarkus limitation and suggestion to fallback to the normal plugin is explained here: https://quarkus.io/guides/tests-with-coverage#coverage-for-tests-not-using-quarkustest Can't wait for the next release! Thanks again. |
|
@xtaixe I must say the combination of the |
|
Honestly, I missed that the fallback is supposed to be used in combination with the extension and not as replacement (with the same configuration as before) 🤦🏻... So it's using online instrumentation now, right? @famod if you can confirm everything works also for multi module projects I might try to give it a go and report back IF I find time cause it's not going to be a quick change since we have different reports for different types of tests, so our configuration is a bit complex and relying on offline instrumentation right now... |
|
@xtaixe It's all "online" which I consider a big plus. |
|
I started reviewing our config and things are starting to come back to me (it was hard getting everything working)... For the end to end tests we do (and how they need to be setup) we are still going to need offline instrumentation, so if the maintainers are ok with it, getting this issue fixed in JaCoCo is still the best solution for us to be able to keep the configuration the same for our different coverage reports (just changing a maven profile with some properties), otherwise it's going to get crazy to get every thing working differently in a big-ish multi module project... |
|
Just FYI, not all cases currently work on Quarkus: quarkusio/quarkus#18559. So hopefully this can still be prioritized... Thanks. |
|
+1 to getting this merged. i have been following it for a while. I have a similiar test case that is fixed with this PR i.e. using jacoco version 0.8.7 - gives 0% code coverage Code is here (mvn test) .. |
|
Thanks! |
Hi, recently I used Jacoco 0.7.2 to test our AppServer, Encountered such a problem:
In Jacoco Offline, are there different threads to synchronisation/write locking for jacoco.exec in one JVM? In order to avoid concurrent writes from different threads running in parallel in one JVM, I changed some code, it can solve our problem temporarily, as below:
Please help to check the issue.
The text was updated successfully, but these errors were encountered: