This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
....which I introduced with my previous commits. Already having test similator for this deadlock. I'll fix it soon (as soon as I'll be online again). Fix itself would be easy but could introduce another problems...
Created attachment 24907 [details] deadlock
Should be fixed. Checking in test/project/NbModuleProjectTest.java; 1.21 --> 1.22 Checking in test/project/ui/customizer/SuiteUtilsTest.java; 1.2 --> 1.3 Checking in NbModuleProject.java; 1.113 --> 1.114
I don't believe the fix is correct. Entering write access from evaluator() is dangerous, because you cannot guarantee that the caller of evaluator() is not in read access - an illegal state transition. I would repeat my previous suggestion of *not* trying to prevent evaluator() from potentially computing a new evaluator twice in parallel threads; it is probably rare, and definitely harmless so long as the final field assignment is synchronized. If you *really* want to prevent this, it is possible, but quite cumbersome: see ProjectManager for a (possibly slightly broken) example.
P1 -> P2. Tested and presuambly works with the current implementation.
Ok, just running under PM.m.readAccess instead of PM.m.writeAccess should be OK. I'll try to write a test which will deadlock the current implementation and than "switch" the access.
Created attachment 25184 [details] tested deadlock
Fixed again. Checking in test/project/NbModuleProjectTest.java; 1.22 --> 1.23 Checking in NbModuleProject.java; 1.114 --> 1.115
*** Issue 67234 has been marked as a duplicate of this issue. ***
it seem's be ok
Note that I just rewrote all this code yesterday. Had to throw out the test for it since it relied on internals of the previous implementation.
Yup, I've noticed this. Are those test irrelevant at all when implementation were rewritten? Or should they be rewritten to fit current state?
I have no idea; not sure what they were testing, other than that a certain usage of a package-private method didn't deadlock something. If there is an externally observable *scenario* that could deadlock somehow (e.g. I edit this file, then delete this platform, etc.) then that can be tested, without reference to impl details of the evaluator.
Hmmm, probably you are right. They just tried to simulate thread dumps I've received. I don't know if it was possible to go few step higher in stack traces with keeping an ability to simulate those deadlocks. But anyway they tested mainly problem in NbModuleProject.evaluator() which was complicated before and is clean and simple now (just a getter). So I believe thay are irrelevant and could be deleted.