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.
Summary: | Deadlock after open group | ||
---|---|---|---|
Product: | platform | Reporter: | err <err> |
Component: | Text | Assignee: | mslama <mslama> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | mentlicher |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Thread dump after hang |
Description
err
2008-06-22 22:05:02 UTC
Created attachment 63225 [details]
Thread dump after hang
Reassigning to "debugger" for evaluation. I need to access the Document from AnnotationProvider.annotate() so that I know *what* I'm annotating. Is it that bad approach?? I do not think so, thus I'm passing to openide.text to reconsider the dual usage of CloneableEditorSupport.RP. It's throughoutput is "1", thus it will not load a document when it's already busy with loading annotations. err, FYI: The threads do not hold the lock. There are in Object.wait() call. I guess I don't quite understand what "locked" means in the following - locked <0x0532b9d0> (a org.openide.windows.CloneableOpenSupport$Listener) It seems like you are saying this means it is in the process of acquiring a lock. If that is the case then I would think it would be in the JVM somewhere. But that can't be the case since after the "locked" line, the stack shows each of the threads to be executing in org.openide.text.CloneableEditorSupport, openDocument in one case and getDocument in the other. If you could explain what this really means I would appreciate it. - locked <0x0532b9d0> (a org.openide.windows.CloneableOpenSupport$Listener) means that the thread has acquired the lock. And it's holding the lock in the upper stack frames. But then it calls Object.wait(). That releases the lock temporarily, until it's notified. Please read http://java.sun.com/javase/6/docs/api/java/lang/Object.html#wait() Thus another thread can take the lock then. And the thread which will call Object.notify()/notifyAll() will also need to acquire the lock. Already fixed in trunk as issue #132662. Fix should be in patch2 for NB 6.1. *** This issue has been marked as a duplicate of 132662 *** |