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.
Nevada build 030502. Linux RH 7.2, GNome JDK 1.4.1_02 I don't know if it is in core. I only tried to open next project by Project Manager. IDE freezed but its processes were taking about 80% of CPU. I was waiting for a few minutes but nothing happened. Durring opening new project I switched to another GNome workspace and back.
Created attachment 10220 [details] Thread dump.
Petr try to evaluate.
ppl, please mark deadlock bugs w/ THREAD keyword. Thx
Very strange. The first thread in the listing is waiting for 0x44c224d8, which is nowhere marked as locked (in fact, it was just released by 5th thread) 2, 3, 4 are waiting to enter the Children.MUTEX as well as 10th (AWT) 5th is also trying to enter as a writer. Mutex questions: *) Trying to upgrade?? *) Does it first free its S status?? *) readresNo -= 2;?? The 5th is marked as runnable although it's in Object.wait() I'm a bit confused.
a question from a different angle: how frequently does this bug happen? In other words, how important is it for 3.5/S1S5 release? (I assume we don't have a reliable testcase to reproduce it :-(
This issue is not reproducible, it has been only once, so decrease priority to P3.
bcs it's not reproducible and the thread dump is not helpful enough, we can't fix it now for 3.5
Somebody else has reported the same problem as a part of issue 33840.
*** Issue 35105 has been marked as a duplicate of this issue. ***
reproduced again (see issue 35105) -> P2
Jesse, don't you see anything suspisious? It seems this problem happens when two readers leave their readAccess "at once" and there is some write request chained. In this thread dump, I see no lock that could cause it, only the strange coincidence in 5th thread (just left the lock the 1st needs and then went sleep, moreover it looks like it either didn't release the lock when going to sleep or (more probable) was just woken up and reaquired the lock as it is marked runnable - why it isn't running then?) If anybody reproduce this problem again - already reported thrice so it should be possible :-( - please make more thread dumps, it may be that the thread got woken up and went back to sleep immediatelly somehow.... Now, in the latest report (issue 35105), the dump is more interesting: Again, two threads are leaving, one correctly waits on M$QC(02D418D8) and the other have it already locked, is again in Object.wait() but is *not* marged runnable and didn't released the lock while waiting: "Default RequestProcessor" daemon prio=2 tid=0x12DF3808 nid=0x204 in Object.wait() [e6af000..e6afd8c] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.openide.util.Mutex$QueueCell.sleep(Mutex.java:1172) - locked <02D418D8> (a org.openide.util.Mutex$QueueCell) at org.openide.util.Mutex.privilegedEnter(Mutex.java:561)
Please don't ask me anything about the current Mutex impl. :-) I don't understand it at all. That is why I have it completely rewritten in a branch...
Is it still happening? No report for half a year ...
I have seen it only once.
*** Issue 36267 has been marked as a duplicate of this issue. ***
OK, the bad news is that it is still happening. The worse news is that it probably is inside of org.openide.util.Mutex and nobody understands why it is happening.
We are not able to safely reproduce the problem and we don't know why and when it is happening. For this reason I can't safely provide a fix for this problem for NB3.6 I suggest waiving this issue for NB3.6 and try to provide some debugging hooks into dev codebase after 3.6 release so we can better understand the problem.
should this be relnoted for 3.6?
*** Issue 41776 has been marked as a duplicate of this issue. ***
Patrick: Probably don't need to be relnoted (if it should, we'd better fix it for 3.6 anyway)
Details: No deadlock, it is a livelock, two (or more) threads are pinging each other through the waiters queue. *) in privilegedEnter, a thread (A) tries to chain itself with quite high priority, but if there are two waiters with the same priority, it is chained after the other one. *) then it wakes the other waiter (B) (which removes it from the queue) *) B re-chains itself, but because it is not the first one (the same prio as A->chain after A), wakes A again and goes to sleep ... and again and again ...
Created attachment 14320 [details] Possible fix
I've integrated the patch. Maybe the code can be simplified more, but it works this way...
Petr, do not forget set appropriate TM if you solve an issue ! Thanks in advance ;)
verified