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.
Product Version = NetBeans IDE Dev (Build 200302100100) IDE Versioning = IDE/1 spec=3.36 impl=200302100100 Operating System = Linux version 2.4.18 running on i386 Java; VM; Vendor = 1.4.1_01; Java HotSpot(TM) Client VM 1.4.1_01-b01; Sun Microsystems Inc. Java Home = /usr/java/j2sdk1.4/sun/jdk1.4.1_01/jre System Locale; Encod. = cs_CZ; ISO-8859-2 Home Dir; Current Dir = /home.local/danielm; /DISKS/storage3/forte/NBdev-last/netbeans/bin IDE Install; User Dir = /home.local/danielm/NBdev-last; /home.local/danielm/.netbeans/dev ------------------------------------------------------------------------------- Nothing to add...please see the FullThreadDump
Created attachment 8872 [details] FTD
The latest TestResult also reflect this issue, but the strange thing about when tests are performed automaticaly is... that ide doesn't hang up....it's just currious...:-/ I'm CC'ing Martin as he told me his recently done some changes in implementation of getting childrens....
and is fully reproductable:-( (or for investigation should I smile ;-) And IDE freez even if I try to access any of nodes under RunTime TAB...so Martin is inocent;-)
Created attachment 8873 [details] here is another FTD caused by selecting SystemProperties node
CCing Jesse. According to Jardas analysis this looks like a bug in Mutex, which I probably won't be able to fix. Jarda suggested Jesse could know what's the problem. He wrote new test into MutextTest.java (testReadWriteRead method) however this test seems to pass.
*** Issue 30792 has been marked as a duplicate of this issue. ***
Sorry, I don't know anything about Mutex really. Have no idea what is going on here.
Changing the summary to reflect the current reality...
sorry, I adding my comments in a bits :-( This must be kinda regression since last WE (Feb-5, 03) In this build or very close arround it had to work... I'll check it for you (hope I find time)... otherwise give mi a note you don't need it
Would be nice. Thanks
*** Issue 30927 has been marked as a duplicate of this issue. ***
Increasing prio to P1, because this bug makes new projects build running on linux completly unusable.
Should be fixed. By replacing notify by notifyAll in Mutex. (as Petr Nejedly) suggested. Please reopen if the problem perists.
:-/ I dind't find when the deadlock has began appearing :-( I think that it is because I'm using modulest from autoupdate, ecpecialu whole XtestTools and this combination leads me to deadlock on whole available builds till last WE which I checked as the last build. I must say thst my colleague dosen't meet this deadlock but he doesn't use NOW those autoupdate's modules... Anyway: The patch which Peter provided me is working for me:-) Thanks
I'm courrious how the bug could be only RESOLVED (and nothing more)?
Should be RESOLVE FIXED
I have to reopen :-( The deadlock isn't immediately after I clicked into RunTime TAB area, but occures after a while.... I still had opened Runtime TAB... and was writing into IZ, then I found again deadlock:-( attaching its FTD....
Created attachment 8897 [details] similar FTD to previous but now the ide freezed after a while of work in RunTime TAB
Created attachment 8900 [details] 2 stacktraces separated by ------, a Deadlock when opening the project node in the project build.
Changed priority to P1, blocks development of project branch.
Jirka has just enter a new DEADLOCK issue #30986 I'm not realy good at diagnosting deadlock in FTDs :-( but with the help of Martin I'm close to idea that it might be even duplicate... even thought thread dumps very differe to each other. Everything ends in incriminated Mutex (but that becasue htere mixt be also problems in VCS? :-/)
Created attachment 8917 [details] a workaround (disables wait cursor)
I attached a workaround which disables using of the wait cursor on expanding node. It prevents this deadlock but the defect must be fixed. (for playing with it you can set/unset the property "netbeans.wait.disabled"). The patch set disable as default. Should I commit this workaround to trunk?
It seems, that the patch works fine. Please commit it to the trunk.
Could one comment on why notifyAll would fix a deadlock? It shouldn't, but it may change the timing. Also could one post the files affected. I enjoy looking into some of the more interesting fixes and such. Thanks!
I commited the temporary workaround (workaround30907.diff) to maintrunk; it should be reverted ASAP.
Jarda wants that bug.
Created attachment 8989 [details] I guess that this is a fix, can anyone try it?
unfortunately, the livelock appeared again ;-(( the stacktraces as same as the stacktraces attached.
I am detecting a few instances of double checked locking in Children.java. We all know this does not work in Java right? Seems like its time for a new PMD Rule :D And could someone give me a tip on detecting the deadlock in a thread dump. The ones from the applets usually say "dealock here" but I can't find it in the dumps from this issue. Thanks.
the double checked locking is on line 1192 of r1.114. I'll take my other thread dump and how to apply the attached patches with NB to the dev mailing list...
Created attachment 8993 [details] Runtime tab nodes, Bundle nodes work fine, please give it a try
To double check locking. Yes, it is there. But please file another issue, the problem is not related to those reported here. To Hrebejk: I hope we are waiting for integration of the last patch. So reassigning to you. We can walk thru the patch tomorrow, if nobody reports problems.
Fine, it seems the last patch really fixes it, works with busy cursor on expand node. All well known cases *doesn't* lead to any livelock on maintrunk. Thanks. The guys on projects branch verify the fix more deep :-)
The last patch seems to fix the problem, thanks Jarda.
Jarda's patch applied Checking in src/org/openide/explorer/view/VisualizerNode.java; /cvs/openide/src/org/openide/explorer/view/VisualizerNode.java,v <-- VisualizerNode.java new revision: 1.30; previous revision: 1.29 done Processing log script arguments... More commits to come... Checking in src/org/openide/nodes/Children.java; /cvs/openide/src/org/openide/nodes/Children.java,v <-- Children.java new revision: 1.115; previous revision: 1.114 done Checking in src/org/openide/nodes/ChildrenArray.java; /cvs/openide/src/org/openide/nodes/ChildrenArray.java,v <-- ChildrenArray.java new revision: 1.10; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in test/unit/src/org/openide/nodes/ChildrenKeysTest.java; /cvs/openide/test/unit/src/org/openide/nodes/ChildrenKeysTest.java,v <-- ChildrenKeysTest.java new revision: 1.4; previous revision: 1.3
Looking at the patch, line 473 inReadAccess should be declared as volatile as it is accessed by seperate threads, outside of any synchronization block. The fact that you are not synchronizing on inReadAccess and that its run in a seperate thread suggests that it is not imperitive that you catch its immediate value. But since you are checking for that value anyway, might as well make the check more (theoretically) reliable.
The temporary workaround30907.diff was removed also, so the busy cursor on expand folder was enabled too.
Ad. volatile variable: No need for that as the variable is accessed by the thread that invokes Mutex.postWriteRequest. Because in spite of that strange name the runnable runs either immediatelly or later, but always in the same thread.
affirmative.
*** Issue 31897 has been marked as a duplicate of this issue. ***
Comfirming as fixed on Sun ONE Studio 5, Standard Edition (Build 030406)
*** Issue 25725 has been marked as a duplicate of this issue. ***
*** Issue 34152 has been marked as a duplicate of this issue. ***
This issue had *4 votes* before move to platform component