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 (or really long delay) using NB 6 | ||
|---|---|---|---|
| Product: | profiler | Reporter: | _ pcw <pcw> |
| Component: | Base | Assignee: | issues@ide <issues> |
| Status: | VERIFIED DUPLICATE | ||
| Severity: | blocker | CC: | jiriprox |
| Priority: | P2 | ||
| Version: | 5.x | ||
| Hardware: | Sun | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | Thread stack dump. | ||
|
Description
_ pcw
2007-03-24 01:52:23 UTC
Created attachment 39906 [details]
Thread stack dump.
Is is reproducible also with disabled profiler? It's most likely a rare race condition. I have no clue how to reproduce it. However, the stack trace on AWT thread attributed to the profiler is not a pretty one. I can't imagine what justification there is to call "waitScanFinished()" on AWT thread, as that is guarranteed to block UI for an indefinite uncancellable period of time. Yes, you're right, I didn't noticed it. Reassigning to profiler for evaluation you are right - the AWT blocking is rather nasty. it's caused by an inappropriate usage of the retouche infrastructure in profiler actions. i'm working on it for m9 *** This issue has been marked as a duplicate of 99225 *** Verified as a duplicate |