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.
I am pretty sure I have seen this deadlock a bunch of other times. Seems to be associated with module reloading, or probably more generally with loader pool changes. Note that two threads are both waiting to use the validator, and no one is actually using it. I see a possible error in the logic in enter/exit: 1. Thread T1 calls enter(). 2. T1 begins body of revalidate (or removeInvalidObject, whichever). 3. T2 calls enter() and blocks because current == T1. 4. T3 calls enter() and blocks for the same reason. 5. T1 calls exit() and sets current == null. 6. T2 is notified, sees current == null, continues, exits. T3 is still blocked and will never continue. Suggest that notify() be replaced with notifyAll(). (Or, this whole awful system cleaned up...)
Created attachment 8352 [details] Thread dump
Sorry, forgot to mention: [dev dec 14].
*** Issue 25605 has been marked as a duplicate of this issue. ***
*** Issue 29809 has been marked as a duplicate of this issue. ***
*** Issue 28648 has been marked as a duplicate of this issue. ***
Jesse, your evaluation is not correct. You forgot about 7. T2 calls exit, sets current == null and notifies T3. Also your suggestion would have no impact because if you would notifyAll the other threads would end up in the wait because of the while loop. I will try to investigate the reason for the deadlock - I have no idea yet.
I am adding Jarda and Radek to Cc: for possible reviews, ideas etc.
The real problem is in those facts: 1. org.openide.loaders.DataObjectPool$Validator.enter is not reentrant (as noted by the genial comment inside the method) 2. there is a thread trying to reenter enter() - this thread causes the other threads to freeze (in Jesses's thread dump this is thread "OpenIDE-request-processor-0") I suggest following fix: the thread would remember the number of times it went through enter. This number would be increased in enter and decreased in exit. In exit the other threads would be notified only in case the counter is zero. Will attach a patch. Please comment the idea - I am not sure enough and don't want screw up things.
dstrupl - You're right, that sounds like the explanation for the deadlock. Rather than patching this already complex code, could it just be simplified dramatically by using Mutex? The Validator class Javadoc fails to explain what the actual requirements for its execution are. It seems to have a number of special behaviors whose purpose is unclear.
Created attachment 8473 [details] Proposed patch
I didn't want to do the rewrite - I am trying to keep the changes as small as possible to be able to easily rollback. I hope to come with new ds - so I am trying to limit the changes to the old system. Simply put I have never found enough courage to do bigger changes to the validation (or recognition). I feel I don't understand the whole system enough to be able to do the changes (in reasonable amount of time).
Fixed in trunk in DataObjectPool.java 1.72
*** Issue 25032 has been marked as a duplicate of this issue. ***
Is DataObjectInvalidationTest stable again (cf. issue #25032)?
The deadlock is gone. But alas - ConcurrentModificationException during the test. I will check it (again <sigh/>).
I will refine the patch. Note that the exception occurs only in cases where there used to be deadlock. So it is sort of safe to leave the source as it is now and I will come back to this tomorrow.
Better fix in DataObjectPool 1.73. Not ideal - I know.
DataObjectInvalidationTest moved back to stable config.
*** Issue 31775 has been marked as a duplicate of this issue. ***
The last fix in DataObjectPool has to be improved with regards of catching the exceptions. Please see #31775. I will try to move the try block to include the line causing the problem.
I will improve the fix but I leave this one as FIXED as it is no longer deadlock. I will reopen #31775 and make the improvement of the fix as fix of that one.
verified. The deadlock dodn't occured again for long time.