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 don't have much to say about this I simply attempting normal development when this happened. To the best of my recollection, I was using the Go To Source (Alt O) feature in the code (code had been parsed into a parser database). When I did this the IDE deadlocked with the attached full thread dump. I might have been doing a compile but I think I did the go to source after seeing a compile error. This error caused data loss. Trace is attached.
Created attachment 5888 [details] Full thread dump of Deadlock
This happened under JDK 1.4.0
I do not see the deadlock in the ftd, maybe I missed something. BTW there isn't involved any code fromcore. There is running some tomcat service - passing to web team to evaluate. If I am wrong, please reassign appropriately. Thanks.
I don't see the deadlock too. All the thread of httpserver looks OK and I don't see any communication here. I don't know what is org.netbeans.core.modules.ChangeFirer.run for. CC'ying Ana - there is HTTP monitor running.
Don't see anything at all wrong in the thread dump either. Note that JDK 1.4.1 "Hopper" gives nicer deadlock detection printouts, this is to be preferred when reporting deadlocks. However it is not broadly available yet. The Tomcat threads look normal to me - just waiting for connections. modules.ChangeFirer is used by the module system; normally dormant. Don't have any hint how to reproduce it, and no information seems available from the dump, so marking WORKSFORME for now.
In response to the comment from Jan Z about not seeing anything in the core causing the problem, neither did I. Please note that the IZ documentation directs one to file against the core when the actual cause is unclear. In response to Jesse, I will see if I can run under 1.4.1. If it happens again, perhaps I will have a better thread dump.
Created attachment 5919 [details] Another deadlock dump under jdk 1.4.1
I added a second dump under 1.4.1 different deadlock, this time on startup. I don't see what 1.4.1 adds to the analysis that I did not see under 1.4.0. I will keep playing with it.
Reopenning because of new stacktrace.
Assigning to David.
Thanks to Jan Zajicek here are related bug reports: 14071, 14538, 14391, 18828. The most relevat seems to be 14071. The bug is due to the fact that the "Image Fetcher" thread dies and MediaTracker waits forever. But the reason for the thread to die is yet unclear. I will try to provide testing patch to discover the reason. Stay tuned.
Created attachment 5929 [details] Test patch
I have attached a patch for release33 branch for file FileURL. The patch is trying to log whether some unexpected exception occur similar to issue 14071. If the IDE will freeze and exception is logged we can find the cause. But it is not sure - there might be more places from where the Image Fetcher thread calls back to our code. Unfortunatelly I don't know the places. Could you please test the patch and let us know whether something occurs in your ide.log after the ide is frozen? Thanks a lot for helping us with this - we were not able to reproduce the error previoussly.
Re. proposed patch: (1) please use -u switch to cvs diff; (2) suggest catching RuntimeException and LinkageError, not general Throwable; (3) use ErrorManager.annotate to chain original cause to IOException.
I added the patch described and ran the test. Just to be unambigous about what I did I have pasted the whole method below. If you have other patches for me please put them into a side branch and I will update my local configuration accordingly. The test produced no result in the ide.log. The code change I made was: /* * @return InputStream or given FileObject. */ public InputStream getInputStream() throws IOException, UnknownServiceException { connect (); try { if (fo.isFolder()) return new FIS (fo); return fo.getInputStream(); } catch (FileNotFoundException e) { ExternalUtil.exception (e); throw e; } catch (Exception x) { ExternalUtil.exception(x); throw new IOException(); } catch (ThreadDeath td) { throw td; } catch (Throwable x) { ExternalUtil.exception (new IllegalStateException()); throw new IOException(); } } I tried this a couple of time. Although I did not get the hang every time, I did reproduce it a couple of times and in no case was any additional information logged to the ide.log.
Created attachment 5956 [details] Modified file SystemAction.java (based on release33 branch (1.53))
Anothere attempt - now I am even trying to fix the problem. There was highly suspicious code in class SystemAction.FixedIcon. I have removed the class entirely - Jesse did the same in trunk already but in release33 the class is still there. So please put the supplied SystemAction.java into your build and try to achieve the freeze. Please let me know how it went. And I really appreciate you helping us to resolve this.
Yes, I removed FixedIcon in the trunk - it interfered with some other modifications I was making, and it looked obsolete to me: Petr Nejedly has already done work to avoid loading action components (e.g. menu items) until they are needed. Also I was not quite sure how it worked and didn't feel safe modifying it. Anyway, Yarda can tell more about this class and whether it is still useful in release33. BTW David could you attach your proposed change as a diff too, just to check?
I would have love to have tested this but it causes the module not to compile. This is partially my fault for not marking down the proper version. The actual version that I am recreating the problem on is the CVS branch of "orion_fcs". I dont know what that corresponds to in the version space here but I chagned the version to FFJ 4.0 ea, which is the closest one I can enter until someone takes care of: http://www.netbeans.org/issues/show_bug.cgi?id=24051 In order to try and test the change to SystemAction.java, I put down the code and tried to recompile the module. Upon doing so I received an error in the build. I will try to figure out the safest way to work around this however doing so will involve a bit of digging into what is being done by preprocessing and compatability so any hints are most welcome. 13javac-workaround: compile-regular: preprocess: compile-preprocessed: [javac] Compiling 10 source files to C:\src\nb_all\openide\compatkit-work [javac] C:\src\nb_all\openide\compatkit-work\org\openide\util\actions\SystemAction.java:195: cannot resolve symbol [javac] symbol : variable FixedIcon [javac] location: class org.openide.util.actions.SystemAction [javac] return FixedIcon.create (SystemAction.class.getResource ("/org/openide/resources/actions/empty.gif")); // NOI18N [javac] ^ [javac] 1 error BUILD FAILED
OK, I fixed up the compile bug and tried that. I still get the same deadlock. To fix the compile bug I first changed: return FixedIcon.create .... to return new ImageIcon .... Later I threw in a stack trace in the compatability copy to make sure I was not hitting that line of code. In any event I was able to recreate the deadlock with both fixes.
FixedImage is useless and code should work without it. Should not the proper way of finding the problem patch the MediaTracker class to print out the exception that is causing the starvation as can be seen here: at java.lang.Object.wait(Native Method) at java.awt.MediaTracker.waitForID(MediaTracker.java:631) ???
Michael, I apologize for the dealy. As Jan Chalupa pointed out there are several bugs reported against MediaTracker and multiprocessor machines (e.g. 4332685, 4327282, 4335416, 4336824, 4339789, 4349620, 4354067). There is a test case attached to the first one here http://developer.java.sun.com/developer/bugParade/bugs/4332685.html but the report states that the bug should have been fixed in 1.4. Could you please check it out (run the test)? Also a search in SUN's bug database (e.g. like this http://search.java.sun.com/Search/java?qt=+%2B4332685&col=obug&category=&state=&query=4332685&submit=+Search+ can give you some pointers to other reports. If it is a different problem we would have to dig deeper in the JDK code (or pass it to the JDK team).
Not dealy but delay ...
I tried the test described in http://developer.java.sun.com/developer/bugParade/bugs/4332 685.html and I am unable to reproduce it under either of the two versions that I encountered 23803 on. Specifically I tried to reproduce 4332685 under: java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) and java version "1.4.0_01-ea" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-ea-b02) Java HotSpot(TM) Client VM (build 1.4.0_01-ea-b02, mixed mode) and java version "1.3.1_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01) Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) I was unable to reproduce the bug with any of the above JDK's. As I noted earlier in this bug, I am able to reproduce 23803 with either jdk 1.4.0 or 1.4.0_01-ea Reading 4332685 I agree the bug I reported and the bugparade bug look related, if not the same.
As it seems to be a bug in MediaTracker I have created a bug report for JDK here: http://developer.java.sun.com/developer/bugParade/bugs/4699667.html and closing this as wontfix on our side. I have added Michael to the interest list for that bug.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.