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.

Bug 231013 - Deadlock when closing css file
Summary: Deadlock when closing css file
Status: RESOLVED DUPLICATE of bug 228991
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 7.4
Hardware: PC All
: P2 normal (vote)
Assignee: Miloslav Metelka
URL:
Keywords:
: 230596 231515 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-06-10 07:59 UTC by Petr Hejl
Modified: 2013-08-19 13:06 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
thread dump (19.51 KB, text/plain)
2013-06-10 07:59 UTC, Petr Hejl 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hejl 2013-06-10 07:59:55 UTC 
Created attachment 135568 [details]
thread dump

NetBeans IDE Dev 201306082301
Comment 1 David Strupl 2013-06-10 13:16:04 UTC 
*** Bug 230596 has been marked as a duplicate of this bug. ***
Comment 2 Miloslav Metelka 2013-06-12 10:38:48 UTC 
The AWT thread notifies document close while one of the listeners

org.netbeans.modules.css.model.api.Model.propertyChange(Model.java:228)

forces openDocument() synchronously which starts "org.openide.text Document Processing" thread which loads the document and begins to fire listeners about document was loaded.
It's a question whether we should allow to reopen document synchronously during notification about its closing.
Comment 3 Miloslav Metelka 2013-06-12 14:50:59 UTC 
Priority set to P2 since this is currently not a beta stopper.
Comment 4 Miloslav Metelka 2013-06-20 16:08:58 UTC 
I'm able to simulate the problem with a CloneableEditorSupportTest.
Depending on machine speed it ends up repetitively opening and closing the document (due to CES$StrongRef being GCed and calling CES.closeDocument()). This makes the machine busy and it possibly leads to OOME being thrown followed by a state when there's typically a single thread waiting in CES.openDocumentImpl() on CES.getLock() but there is no thread that would awaken it.
Comment 5 Miloslav Metelka 2013-06-20 16:27:49 UTC 
*** Bug 231515 has been marked as a duplicate of this bug. ***
Comment 6 Miloslav Metelka 2013-08-19 13:06:04 UTC 
Fix of issue #228991 does CES.closeDocument() in RP thread and allows for synchronous CES.openDocument() from the close notification (there's a CloneableEditorSuppoortOpenCloseTest added for it) so this issue should be resolved.

*** This bug has been marked as a duplicate of bug 228991 ***