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 111069 - Deadlock after external modification(?)
Summary: Deadlock after external modification(?)
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Petr Nejedly
URL:
Keywords: RANDOM, THREAD
Depends on:
Blocks:
 
Reported: 2007-07-26 10:21 UTC by Martin Krauskopf
Modified: 2008-12-22 13:51 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
TD.txt (15.45 KB, text/plain)
2007-07-26 10:22 UTC, Martin Krauskopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Krauskopf 2007-07-26 10:21:55 UTC
Actually not sure, when. Firstly got AE from issue 111068, then quite soon got this deadlock (presumably). Attaching
thread dump.
Comment 1 Martin Krauskopf 2007-07-26 10:22:23 UTC
Created attachment 45758 [details]
TD.txt
Comment 2 Vitezslav Stejskal 2007-07-26 11:17:23 UTC
I am not sure what exactly went wrong, but the problem seems to be in CloneableEditorSupport in document reloading. All
threads are apparently waiting on the document to be reloaded, but no other thread seems to be loading it. It could be a
side effect of #111068.
Comment 3 Petr Nejedly 2007-07-31 14:28:28 UTC
Thread "Default RequestProcessor" (tid=0x95d6c400) would like to load the document everybody is waiting for, but it
can't as it needs write access to the document, but the thread "HintsController worker" (tid=0x9689a000) keeps read access.

There was no reload happening ("HintsController worker" found status=DOCUMENT_NO), but AnnotationsHolder (few stack
frames earlier) somehow obtained the reference to the document being loaded.

That means that HintsControllerImpl.setErrorsImpl():103 maintained to sucessfully get AnnotationsHolder instance
with proper doc set (that is, editorCookie.getDocument() passed), yet finds no doc/DOCUMENT_NO a while later (even under
doc's read access.

I still don't fully understand how can this happen.

Comment 4 Petr Nejedly 2007-07-31 14:38:38 UTC
Ih, now I see. This is clearly a consequence of issue 111068, but we need to make CES more robust.
The reloading task failed (actually just one of the document listeners fired an Error), but the internal structures were
left inconsistent (doc != null while status == DOCUMENT_NO).

There should be two fixes:
1. Clear the doc field if the loading effort led to DOCUMENT_NO (to prevent this deadlock)
2. (optional) Survive errors from listeners, keep on reloading.
Comment 5 Petr Nejedly 2007-07-31 14:53:25 UTC
#1 fixed:

openide/text/src/org/openide/text/CloneableEditorSupport.java,v1.35