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 33663 - [java-mdr] Unmounting a filesystem is not safe
Summary: [java-mdr] Unmounting a filesystem is not safe
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks: 35769
  Show dependency tree
 
Reported: 2003-05-15 18:39 UTC by Martin Matula
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
NPE stacktrace (3.46 KB, text/plain)
2003-05-15 18:40 UTC, Martin Matula 		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 Martin Matula 2003-05-15 18:39:35 UTC 
When I am in the navigation tree and navigate to
some class, then I unmount the filesystem that the
class resides in, I get infinite sequence of NPEs
(see the attached stacktrace).
Similar exceptions occur when the metadata
updating is in progress while unmounting the
filesystem.
Comment 1 Martin Matula 2003-05-15 18:40:25 UTC 
Created attachment 10320 [details]
NPE stacktrace
Comment 2 Timothy.n Jones 2003-05-20 17:28:02 UTC 
I get a different stacktrace when unmounting a filesystem.  I see five
apparently identical copies.

java.lang.NullPointerException
	at
org.netbeans.mdr.handlers.InstanceHandler._handleGetR(InstanceHandler.java:103)
	at
org.netbeans.jmi.java.source.JavaSource$Impl.getJavaPackage(Unknown
Source)
	at
org.netbeans.modules.java.bridge.SourceElementImpl.getPackage(SourceElementImpl.java:79)
	at
org.netbeans.modules.java.bridge.SrcElementImpl.getPackage(SrcElementImpl.java:162)
	at org.openide.src.SourceElement.getPackage(SourceElement.java:100)
	at org.netbeans.modules.java.JavaNode.resolveIcons(JavaNode.java:552)
	at
org.netbeans.modules.java.JavaNode$StateUpdater.actionPerformed(JavaNode.java:888)
	at javax.swing.Timer.fireActionPerformed(Timer.java:271)
[catch] at javax.swing.Timer$DoPostEvent.run(Timer.java:201)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
	at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
	at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
Comment 3 Pavel Flaska 2003-09-25 16:12:27 UTC 
IMO it is caused by the asynchronous updating JavaNode. JavaNode
starts updating its state asnynchronously. Unfortunately when bridge
delegates the work to the MDR, the storage is already umounted and the
proper MOFIDs (or anything else) could not be found.
Comment 4 Martin Matula 2003-12-08 17:04:21 UTC 
seems that with the new insfrastructure this is no longer a problem