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.
Pre-RC1 build #200504171930 of NetBeans 4.1 Windows 2000, JDK 1.4.2_02 build #03 Description: ============ Today I can't start IDE or use it on platform mentioned above in spite of using it just fine last week. It always deadlocks - firstly at startup, now after classpath is scanned and I tough project node. I will try to provide you with more information as I find some. I only had one web project opened with few files of different type (XML, DTD, Java, TAG, TLD or JSP). I am attaching full thread dumps of startup and in-run deadlocks. What I did: =========== 1. I started the IDE 6 days ago with empty userdir. 2. I created new sample web application project. 3. I generated files mentioned above and tested code completion, syntax highlighting, generated handlers etc. 4. I closed the IDE and launched it today but it didn't even start. 5. Later it started fine but froze when I touched my web project node.
Created attachment 21869 [details] Thread dump of startup deadlock.
Created attachment 21870 [details] Thread dump of deadlock when project node was touched.
Radek please look at this ....
I have some good news. My latest investigations show that it works fine in RC1 (#200504200735) and/or JDK 1.5.0_03 build #06. However, I can easily reproduce the deadlock with my userdir in pre-RC1 and 1.4.2. Let me please know if you want me to produce more thread dumps or attach the userdir or try another build/Java platform. =============================================================== Build | JDK 1.4.2_02 build #03 | JDK 1.5.0_03 build #06 ----------+--------------------------+------------------------- Pre-RC1 | Dead locks constantly | Works fine RC1 | Works fine | Works fine ===============================================================
This issue is probably JDK specific.
Petr,please write up some comments why usage of Mutex.Privileged from FileBasedFileSytem should stop its threads in wait. Maybe I overlooked something, but I don't see any reason for that.
Mutex.Privileged expects you're careful enough to not forget to unlock it. You have to very carefuly use the pattern of: mp.enterXAccess(); try { ... } finally { mp.exitXAccess(); } If you fail to unlock it somewhere, it would be impossible to track it from the thread dump. If you leak out the mp reference, noone can guarantee the behaviour. In the dumps, I see just two threads trying to enter but noone holding the lock. It can be exactly the case of missed exitXAccess(), maybe in older version of the code (if not reproducible any more).
There were no fixes between pre-RC1 and RC1 that should affect it. Sorry, I have even no idea where to put some logging, trace information or how to trap it at all. AFAIK to reproduce this problem, there is necessary to run Pre-RC1 NB on J.Kovalsky's computer with its userdir, on JDK 1.4.2_02 build #03. I can't decide whether there might be problem in Mutex implementation. Petr, please evaluate.
Jirka, please try to investigate. For example if there was possible to reproduce it with your userdir on arbitrary machine - it could help.
Okay, I'm gonna deep dive into this problem ...
I don't know why those 2 threads are in wait. If there is no magic and this report is right then probably must be problem somwere in Mutex. Reassigned to Petr.
After one more day spent on reproducing it elsewhere I agree with closing this bug as invalid. I used JDK 1.4.2_02 build #03 to launch Pre-RC1 with the same userdir and project on my notebook but couldn't invoke the bug again. I have to admit that the computer where I first encountered the bug had some performance problems and yesterday has finally crashed (memory failure) so I can't reproduce it there any more. If you are sure your code is okay, I have no objections against closing this defect.
Changing back component. Sorry for another mail ...
Ok, WORKSFORME
Verifying then ...