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 146008 - no document although status is 2; doc=StrongRef[doc=null,super.get=null]
Summary: no document although status is 2; doc=StrongRef[doc=null,super.get=null]
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: mslama
URL: http://hudson4qe.czech.sun.com/job/Da...
Keywords: RANDOM, TEST
: 140194 143628 144747 146079 (view as bug list)
Depends on: 152839
Blocks:
  Show dependency tree
 
Reported: 2008-09-03 08:42 UTC by Jaroslav Tulach
Modified: 2009-02-19 22:53 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Patch described above (1.70 KB, text/plain)
2008-09-12 15:45 UTC, mslama
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-09-03 08:42:17 UTC
From time to time the openide.text and other tests are failing on assert in the code. Moreover during my NetBeans 
Platform workshop in Brno, we used NetBeans 6.5 beta and were able to observe the same bug as well. I am not aware of 
this problem being in 6.1 - the tests were stable at that time. There had to be some regression recently. I'd like it 
to be fixed, as it may have very destabilizing impact on IDE and Platform users.

Caused by: java.lang.AssertionError: no document although status is 2; doc=StrongRef[doc=null,super.get=null]
        at org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:750)
        at org.openide.text.CloneableEditorSupport.openDocumentCheckIOE(CloneableEditorSupport.java:725)
        at org.openide.text.CloneableEditorSupport.openDocument(CloneableEditorSupport.java:720)
        at org.openide.text.DataEditorSupport.openDocument(DataEditorSupport.java:400)
        at org.openide.text.CloneableEditorSupport.open(CloneableEditorSupport.java:434)
        at org.openide.loaders.DefaultDataObjectHasOpenTest$2.run(DefaultDataObjectHasOpenTest.java:298)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Comment 1 Lukas Hasik 2008-09-04 11:00:17 UTC
*** Issue 146079 has been marked as a duplicate of this issue. ***
Comment 2 mslama 2008-09-10 19:09:27 UTC
*** Issue 143628 has been marked as a duplicate of this issue. ***
Comment 3 mslama 2008-09-12 15:30:54 UTC
I see 3 API entry points:
1. StyledDocumentCES.openDocument() - I can simply create strong ref to document and just before return from
CES.openDocument() I will set it back to weak:
            StyledDocument doc = openDocumentCheckIOE();
            setDoc(doc,false);
            return doc;

2. StyledDocument CES.getDocument() - the same as case 1.

These 2 will fix invalid state and also make sure that document is not loaded more than once issue #143628.

3. Task CES.prepareDocument() - I can set reference to weak just before it returns Task or add task listener and set
reference to weak once task is finished. As there is no guarantee there is any document after task is finished and there
is no API bridge how to make sure that API client gets document created by CES.prepareDocument it does not matter. Still
it means that document can be loaded more than once during processing this task. Setting reference to weak in the end of
task just make window for gc smaller. Both variants will make sure that created document can be gc'ed later.
Comment 4 mslama 2008-09-12 15:45:16 UTC
Created attachment 69760 [details]
Patch described above
Comment 5 mslama 2008-09-15 11:00:45 UTC
*** Issue 144747 has been marked as a duplicate of this issue. ***
Comment 6 mslama 2008-09-15 11:12:09 UTC
Fixed bbbbb1aa15b5.

Task listener is added and reference is reset when task finishes.
Comment 7 Jesse Glick 2008-09-15 12:44:20 UTC
BTW please write the changeset as e.g.

  core-main #bbbbb1aa15b5

so that it gets hyperlinked correctly by

http://wiki.netbeans.org/BrowserTools#section-BrowserTools-LinkToMercurialChangesets
Comment 8 Quality Engineering 2008-09-17 06:05:18 UTC
Integrated into 'main-golden', will be available in build *200809170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bbbbb1aa15b5
User: Marek Slama <mslama@netbeans.org>
Log: #146008: Keep strong reference to document during loading to avoid premature gc.
Comment 9 mslama 2008-09-23 11:50:44 UTC
*** Issue 140194 has been marked as a duplicate of this issue. ***
Comment 10 Jesse Glick 2008-09-26 15:34:50 UTC
ReusableEditor2Test has been randomly timing out in NB-Core-Build. And just today I ran it on my laptop, getting a stack
trace and then the test froze and had to be killed:

Testsuite: org.openide.text.ReusableEditor2Test
(Opening)
(Opened)
(Opening)
(Opened)
(Opening)
(Opened)
(Opening)
(Opened)
(Opening)
(Opened)
(Opening)
(Opened)
(Opening)
(Opened)
Sep 26, 2008 10:31:36 AM org.openide.util.RequestProcessor$Processor doNotify
SEVERE: null
java.lang.AssertionError: no document although status is 2; doc=StrongRef[doc=null,super.get=null]
        at org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:779)
        at org.openide.text.CloneableEditorSupport.openDocumentCheckIOE(CloneableEditorSupport.java:754)
        at org.openide.text.CloneableEditorSupport.openDocument(CloneableEditorSupport.java:744)
        at org.openide.text.CloneableEditor$DoInitialize.initNonVisual(CloneableEditor.java:348)
        at org.openide.text.CloneableEditor$DoInitialize.run(CloneableEditor.java:250)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
BUILD STOPPED (total time: 1 minute 21 seconds)

I am marking it random again: core-main #6d20df29b1e5
Comment 11 Quality Engineering 2008-09-27 05:38:59 UTC
Integrated into 'main-golden', will be available in build *200809270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6d20df29b1e5
User: Jesse Glick <jglick@netbeans.org>
Log: #146008: still does not pass consistently.
Comment 12 mslama 2008-09-30 14:17:12 UTC
New improvement core-main #144e1f70d7b3
Comment 13 mslama 2008-09-30 14:28:42 UTC
I added separate counters for 3 API methods which create document. This way strong reference to document should not be
removed too soon. At least this fixes last problem: prepareDocument -> during loading document some document listener
called getDocument so strong reference was removed before prepareDocument finished. It is not possible now.
Comment 14 mslama 2008-10-16 14:35:26 UTC
Additional fix for openAtImpl to fix ReusableEditorTest and ReusableEditor2Test.

core-main #6306c819ae7b
Comment 15 Quality Engineering 2008-10-18 15:52:59 UTC
Integrated into 'main-golden', will be available in build *200810181401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6306c819ae7b
User: Marek Slama <mslama@netbeans.org>
Log: #146008: Keep strong reference to document at openAtImpl.
Comment 17 mslama 2008-11-20 11:15:23 UTC
Weird. I checked. Failure is from latest source but I do not see any way how this could happen. There is simple case
when only CES.openDocument is called for given CES instance and reference to document is strong in this case. Only
possibility is that code in test goes other way. I have to add logging to test to see what actually happens on build
machine.
Comment 18 mslama 2008-11-20 14:53:11 UTC
Problem is caused by fact that actual value of wek reference to document is not synced with value of documentStatus
flag. When reference is cleared by gc there is time window when reference is null but documentStatus is DOCUMENT_READY.
It must be fixed - I must first get reference to document and assign it to local variable so that it cannot be gc'ed. If
document reference is null it means documentStatus DOCUMENT_NO. If document reference is not null then I can check
documentStatus.
Comment 19 mslama 2008-11-21 15:49:11 UTC
core-main #bc4910456f73
Comment 20 Quality Engineering 2008-11-22 04:45:56 UTC
Integrated into 'main-golden', will be available in build *200811220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bc4910456f73
User: Marek Slama <mslama@netbeans.org>
Log: #146008: Fix documentStatus when reference to document is null but documentStatus is not yet synced.