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 107560 - 2mb char[] being referenced by lastModifyUndoEdit
Summary: 2mb char[] being referenced by lastModifyUndoEdit
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@editor
URL:
Keywords:
Depends on:
Blocks: 98405
  Show dependency tree
 
Reported: 2007-06-21 02:23 UTC by Samaresh Panda
Modified: 2007-11-05 13:44 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
heap dump image 1 (51.08 KB, application/octet-stream)
2007-06-21 02:23 UTC, Samaresh Panda 		Details
instance view of char[] (69.34 KB, application/octet-stream)
2007-06-21 02:24 UTC, Samaresh Panda 		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 Samaresh Panda 2007-06-21 02:23:19 UTC 
xdm model uses ExtSyntaxSupport to create tokens. When hl7 schemas (fields.xsd) are loaded as a result of creating xdm
model, I can see that 2mb of char[] is occupied by lastModifyUndoEdit.

See attached heap dump images. hl7 (fields.xsd) schema can be found in xml/xdm unit tests.
Comment 1 Samaresh Panda 2007-06-21 02:23:54 UTC 
Created attachment 44129 [details]
heap dump image 1
Comment 2 Samaresh Panda 2007-06-21 02:24:27 UTC 
Created attachment 44130 [details]
instance view of char[]
Comment 3 Miloslav Metelka 2007-06-25 09:30:42 UTC 
 The lastModifyUndoEdit was created and maintained for fix of the issue 8692. To fix that deadlock (between UndoManager
and Document locking) the undoing could be invoked asynchronously so the document has to check whether the undoable edit
being undone is really the last one performed.
 Currently the undoing is again done synchronously and UM pre-locks the document first before locking itself to prevent
deadlock so the funcionality of lastModifyUndoEdit should no longer be required.
 We can clear the field after BaseDocument.read() relatively safely because we can rely that the UM's queue will be
cleared as well (by CloneableEditorSupport) after document's load.
 This is not P1 downgrading to P2.
Comment 4 Miloslav Metelka 2007-06-25 12:53:51 UTC 
Checking in BaseDocument.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v  <--  BaseDocument.java
new revision: 1.143; previous revision: 1.142