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.
Hi, I use <nbinstaller> to reinstall my modules in the IDE. Sometimes it freezes, consumes a lot of memory and throws OutOfMemoryException. A thread dump is attached. thank you
Created attachment 9318 [details] Threads dump
This bug is not nbbuild bug it probably belongs to ANT module.
Nothing to do with nbbuild nor Ant that I can see, just a run-of-the-mill core deadlock. Tim, how about some version information of NetBeans here... please set the Version field according to the version of NB you are using, and in a comment give the precise build number.
Here is the version number NetBeans IDE Dev (Build 200303041809) I built it myself from the trunk
Hi, the javadoc of org.openide.util.RequestProcessor.Task.waitFinished says that "It check the current thread if it is request processor thread and in such case runs the task immediatelly to prevent deadlocks.". In the thread dump is: "Default RequestProcessor" daemon prio=2 tid=0x15AD5A28 nid=0x3a8 in Object.wait() [181cf000..181cfd88] at~java.lang.Object.wait(Native Method) - waiting on <04573DD0> (a org.openide.util.RequestProcessor$Task) at~java.lang.Object.wait(Object.java:426) at~org.openide.util.Task.waitFinished(Task.java:85) - locked <04573DD0> (a org.openide.util.RequestProcessor$Task) at~org.openide.util.RequestProcessor$Task.waitFinished(RequestProcessor.java:437) at~org.openide.loaders.FolderList.waitProcessingFinished(FolderList.java:230) This seems to me like if org.openide.util.RequestProcessor.Task.waitFinished failed to recognize the request processor thread. I am reassigning to pnejedly to investigate.
It has nothing to do with the priority inversion in the RP. The problem is that exec_tasklist thread holds 036CCB40, but wants to list a folder, but the Folder recognizer thread needs 036CCB40 to return the result. Is the cause the notification under the lock?
Petr, I would say you're right. If notification at org.netbeans.core.projects.SystemFileSystem.notifyMigration(SystemFileSystem.java:432) was not performed under MFO lock, deadlock would vanish. Radku, is this possible to achieve? Scheduling for 4.0.
The update() in MFO:373 runs insite atomic action, so the notifications should be done later (and after leaving the synchronized section), right?
OK. FileStatusEvents were postponed also after atomic block. /cvs/openide/src/org/openide/filesystems/FileSystem.java new revision: 1.76; previous revision: 1.75
ok