Bug 196734 - [70cat] AssertionError: docViewEndOffset=2571 < endOffset=4882
[70cat] AssertionError: docViewEndOffset=2571 < endOffset=4882
Status: VERIFIED FIXED
Product: editor
Classification: Unclassified
Component: Painting & Printing
7.0
All All
: P1 (vote)
: 7.0
Assigned To: Miloslav Metelka
issues@editor
EXCEPTIONS_REPORT
: 70_HR_FIX
: 196869 197056 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-15 16:03 UTC by alied
Modified: 2011-04-08 07:55 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (4.39 KB, text/plain)
2011-03-15 16:03 UTC, alied
Details
stacktrace (5.52 KB, text/plain)
2011-03-17 15:40 UTC, alied
Details

Note You need to log in before you can comment on or make changes to this bug.
Description alied 2011-03-15 16:03:47 UTC
Build: NetBeans IDE Dev (Build 201103140400)
VM: Java HotSpot(TM) Client VM, 19.1-b02, Java(TM) SE Runtime Environment, 1.6.0_24-b07
OS: Windows XP

User Comments:
alied: I pressed nter, then I pressed Ctrl+Z a couple times (i didn't actually meant to press Enter)




Stacktrace: 
java.lang.AssertionError: docViewEndOffset=2571 < endOffset=4882
   at org.netbeans.modules.editor.lib2.view.ViewBuilder.<init>(ViewBuilder.java:153)
   at org.netbeans.modules.editor.lib2.view.ViewUpdates.buildViews(ViewUpdates.java:175)
   at org.netbeans.modules.editor.lib2.view.ViewUpdates.removeUpdate(ViewUpdates.java:476)
   at sun.reflect.GeneratedMethodAccessor227.invoke(GeneratedMethodAccessor227.java:0)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
Comment 1 alied 2011-03-15 16:03:50 UTC
Created attachment 107023 [details]
stacktrace
Comment 2 Miloslav Metelka 2011-03-16 18:33:24 UTC
Thanks for the report.
Question: do you have code folding turned on by default or do you collapse folds during your work?

I finally realized that the problem can be a view hierarchy constructed for a fold preview not the "main" view hierarchy for a document. The tooltip preview constructs an editor pane with the same document as the edited one and a client property that demarcates fold boundaries for a fold preview. Possible ongoing document modifications would get handled by that view hierarchy. But due to operation over just a part of a document the view updates are more complex and as my just added tests have shown there are certain problems in such case similar to the reported exceptions. I'll try to both improve stability of view updates for a document portion operation and also possibly deactivate the view hierarchy immediately after tooltip closing.

Btw this all would also correspond to the randomness of the exception since the liveness of the tooltip pane (after it becomes invisible) is in fact determined by the garbage collector operation.

Marking as P1 since this must be resolved into 7.0.
Comment 3 alied 2011-03-16 18:52:50 UTC
Yes, actually I automatically fold all but functions. besides, also functions not directly related to my current work get folded too.
These type or error mostly happen while editing and I (temporaryly)break the sintax (hence the creation of a tooltip, a badge, etc.)
Comment 4 alied 2011-03-17 15:40:04 UTC
Created attachment 107085 [details]
stacktrace

anytime I change something in the GUI builder I get this exception
Comment 5 Exceptions Reporter 2011-03-17 15:40:15 UTC
This bug already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=177485
Comment 6 Miloslav Metelka 2011-03-17 16:01:30 UTC
I have implemented a fix that disables tooltip's view hierarchy updates once the tooltip gets invisible.
Rest of the problem will be fixed in terms of issue 196814 but it's non-fatal for the current usage. A thorough fix would be complex and it could destabilize the code which is undesirable at this time prior 7.0 release.

http://hg.netbeans.org/jet-main/rev/7e07e455c219
Comment 7 Quality Engineering 2011-03-18 09:47:07 UTC
Integrated into 'main-golden', will be available in build *201103180400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7e07e455c219
User: Miloslav Metelka <mmetelka@netbeans.org>
Log: #196734 - AssertionError: docViewEndOffset=2571 < endOffset=4882 - View Hierarchy stops listening on document updates once fold tooltip preview gets closed.
Comment 8 Jan Lahoda 2011-03-18 12:40:55 UTC
alied, could you please test the 201103180400 build if it solves the problem? Thanks.

Jara, if the last patch would fix the problem, I would like to transplant it to release70 on Monday. Is that OK with you? Thanks.
Comment 9 Jaromir Uhrik 2011-03-19 08:09:39 UTC
Since I don't have reproducible testcase I am not able to verify. If the reporter verifies the fix then I agree with integration to 7.0.
alied, could you please verify that the issue is not reproducible in the build 201103180400 of the trunk?
Thanks.
Comment 10 alied 2011-03-19 21:45:49 UTC
Still happening, but takes longer to biegin, however, once it hapens, keeps happening frequently. Also the Exception reporter is not working. It just shows the outer frame and nothing else(I guess this should be a new issue), not blocking and closes when you click on the X. I attach some logs.

Product Version: NetBeans IDE Dev (Build 201103180400)
Java: 1.7.0-ea; Java HotSpot(TM) Client VM 21.0-b04
System: Windows XP version 5.1 running on x86; Cp1252; es_ES (nb)
Comment 11 Miloslav Metelka 2011-03-20 20:43:32 UTC
:( I thought I've finally eliminated it.
Anyway, alied, thanks for testing. Please attach the logs. In this stage (before FCS) I will attempt to recreate the view hierarchy completely once the particular exception gets thrown (and consume the exception silently).
Comment 12 Miloslav Metelka 2011-03-23 14:54:01 UTC
alied, could you please attach the logs? The assertion for which the issue is entered

java.lang.AssertionError: docViewEndOffset=2571 < endOffset=4882
org.netbeans.modules.editor.lib2.view.ViewBuilder.<init>(ViewBuilder.java:153)

is no longer present in the code so unless you provide the logs I would have to close the issue as fixed.
I'm wondering whether to integrate the fix into release70. You said that the issue takes longer to happen (how much approximately?) so probably it makes sense to integrate it, right?
Comment 13 Miloslav Metelka 2011-03-23 22:48:23 UTC
IMHO it's desirable to port the fix into release70 since it can eliminate the cases caused by stale tooltip.
Comment 14 Miloslav Metelka 2011-03-23 23:05:23 UTC
Integrated into release70:
7e07e455c219 transplanted as eaca59129d5c
Comment 15 Miloslav Metelka 2011-03-24 15:16:14 UTC
*** Bug 196869 has been marked as a duplicate of this bug. ***
Comment 16 Miloslav Metelka 2011-03-24 22:23:04 UTC
*** Bug 197056 has been marked as a duplicate of this bug. ***
Comment 17 Jaromir Uhrik 2011-04-08 07:53:42 UTC
No regression found so marking this issue as Verified.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo