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 15957 - ISE thrown when switching projects
Summary: ISE thrown when switching projects
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-09-27 10:23 UTC by Milan Kubec
Modified: 2007-09-26 09:14 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
two exception stack traces (9.10 KB, text/plain)
2001-09-27 10:24 UTC, Milan Kubec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kubec 2001-09-27 10:23:04 UTC
I've created two projects and was switching between them and in both projects
there were some files oppened. The first IllegalStateException was thrown during
switching projects and the second one after clicking exit in IDE, but after
throwing exception IDE didn't quit.
Comment 1 Milan Kubec 2001-09-27 10:24:09 UTC
Created attachment 2728 [details]
two exception stack traces
Comment 2 Jesse Glick 2001-09-29 10:47:12 UTC
The second exception I believe I fixed very recently in DataNode,
though I did not consider it reproducible. So assuming this is fixed
for now, if you see it again please reopen of course (with a separate
issue! it is unrelated to the first exception).

The first exception is I think a bug in the java module:
SiblingListener in this case is posting an asynchronous update of the
selected node for the editor top component. Probably what happens is
that the data object is invalidated due to some filesystem being
unmounted (perhaps?); the Java parser is notified of this, and decides
to fire a change; this in turn decides to change the node selection,
but do it later; when the time comes, an attempt is made to set the
selection to the node delegate, but by this time the object is invalid
and really the editor should be closing or even already closed.
getNodeDelegate at that point is illegal. I would suggest that
JavaEditorComponent.selectElementsInOffset simply check for an invalid
object and if so set an empty selection. Or some other code could
check earlier on for invalid data objects and perhaps skip more
unnecessary tasks, I don't know.
Comment 3 Svata Dedic 2001-10-03 10:09:57 UTC
I really don't know how it come to that the EditorComponent is 
*STILL* the activated one, but its dataobject is not valid (there's 
a check in the JavaEditor). I will put additional check - whether 
the DataObject is valid, but it does not solve anything. If the 
dataobjct is invalidated asynchronously between this check and call 
for the node delegate, the ISE will appear again.
IMO throwing ISE from DataObject.getNodeDelegate() is a very bad 
thing (tm), since I can't properly synchronize to check the state & 
get the node atomically. Advices welcome.

Comment 4 Jesse Glick 2001-10-03 21:20:16 UTC
Yes we know there is a possible race condition, however this has not
been observed, whereas many fixable bugs involving significant delays
have been observed. I don't see any way to avoid the race condition
other than by completely changing the threading model for datasystems,
which we are certainly not about to do now. So just don't worry for
now--fix the obvious bug and leave the potential race condition. We
might still disable the ISE from getNodeDelegate before release, but
in the meantime it is helpful for finding certain kinds of code errors
elsewhere. (Actually I am not quite sure how to correctly disable the
ISE since this would require some sort of synchronization, which needs
to be guarded against deadlocks, but it should be possible with a
little work.)
Comment 5 Svata Dedic 2001-10-04 11:13:42 UTC
Fixed -- calls from JavaEditor & JavaParserGlue are now guarded by a 
check for DataObject validity.
Comment 6 Jan Becicka 2001-10-19 13:06:22 UTC
Milan, can you verify this fix? Thanks
Comment 7 Milan Kubec 2001-10-19 13:42:18 UTC
Verified in dev-20011019
Comment 8 Quality Engineering 2003-07-01 13:16:12 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.