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.
[Nb build 200204040100, jdk 1.4.1] Steps to reproduce: 1) start IDE and don't copy anything into Clipboard 2) press Ctrl-V in any edtitor pane or any text field. e.g. in Edit > Search Filesystems > Substring: Annotation: Exception occurred in Request Processor java.lang.InternalError at org.openide.util.Mutex.readAccess(Mutex.java:163) at org.netbeans.core.NbPresenter.show(NbPresenter.java:676) at org.netbeans.modules.search.SearchPanel.showDialog(SearchPanel.java:268) at org.netbeans.modules.search.SearchPerformer.performAction(SearchPerformer.java:143) at org.netbeans.modules.search.SearchPerformer.performAction(SearchPerformer.java:202) at org.netbeans.modules.search.RepositorySearchAction.performAction(RepositorySearchAction.java:58) at org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSystemAction.java:69) at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:108) at org.openide.util.Task.run(Task.java:138) at org.openide.util.RequestProcessor$Item.run(RequestProcessor.java:381) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:533) ------ in Java Editor: java.io.IOException: Failed to get selection targets at sun.awt.datatransfer.ClipboardTransferable.getClipboardFormats(Native Method) at sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferable.java:64) at sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:80) at javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:811) at javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1183) at javax.swing.text.JTextComponent.paste(JTextComponent.java:1161) at org.netbeans.editor.BaseKit$PasteAction.actionPerformed(BaseKit.java:1139) at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:133) at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1504) at javax.swing.JComponent.processKeyBinding(JComponent.java:2435) at javax.swing.JComponent.processKeyBindings(JComponent.java:2470) at javax.swing.JComponent.processKeyEvent(JComponent.java:2398) at java.awt.Component.processEvent(Component.java:4889) at java.awt.Container.processEvent(Container.java:1525) at java.awt.Component.dispatchEventImpl(Component.java:3585) at java.awt.Container.dispatchEventImpl(Container.java:1582) at java.awt.Component.dispatchEvent(Component.java:3426) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1700) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:571) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:743) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:676) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:537) at java.awt.Component.dispatchEventImpl(Component.java:3455) [catch] at java.awt.Container.dispatchEventImpl(Container.java:1582) at java.awt.Window.dispatchEventImpl(Window.java:1569) at java.awt.Component.dispatchEvent(Component.java:3426) at java.awt.EventQueue.dispatchEvent(EventQueue.java:445) 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)
The root problem is in JVM Clipboard impl. Editor module should guard itself against such errors.
fixed in [maintrunk] as for editor. Editor is safe now. Reassigning back to core. /cvs/editor/libsrc/org/netbeans/editor/BaseKit.java,v <-- BaseKit.java new revision: 1.79; previous revision: 1.78
Passing to Petr - to evaluate problem in Mutex. Second part (problem in editor is fixed).
The Mutex case is a bit difficult. In fact, when it throws InternalError, it _is_ internal error. See: User is passing Mutex.Action, which have just one method, Object run(), which don't declare any exception, so it can throw only RuntimeException or Error. Deeper in the implementation, there are two branches: 1) from AWT (not our case): Mutex catches Exceptions, rethrows them if RuntimeException, Errors are passed through directly, so it can happen only for checked exceptions. 2) Outside of AWT (our stacktrace is from RP): We're using EventQueue.invokeAndWait(). we're catching all Exceptions ourself so we can't get InvocationTargetException. Errors are not catched at all and will be reported through AWT dispatcher. If the catched exception is RuntimeException, we're rethrowing it in the originating thread, so the InternalError can be thrown only for checked exceptions _AND_ InterruptedException from invokeAndWait. Now, for the checked exceptions it is clear, it IS internal error, but what to do for InterruptedException? The Mutex.Action is may be still performing or even not yet started, so the return is too fast. I've improved reporting of the original exception so we can see what kind of exception have caused it. Lets see.
[Nb Build 200204150100, jdk1.4.1]
Thanks, but I need you to reproduce it (I can't reproduce it myself), and attach the original exception that caused the InternalError.
I'm sorry the attachement somewhere stucked. Steps to reproduce: ------------------- 1) create e.g. new DTD document 2) right click the document's node and choose Rename 3) press Ctrl-V in New Name text field
Created attachment 5414 [details] InternalError with original exception:
That is exactly the case I was thinking about: A method declared to not throw anything throws checked exception. It usually can't happen, it may happen only if you compile the implementation of some method throwing an exception and then change definition of the method and recompile it (bad product of compilation) Or if you're throwing the exception from inside the native code, of course (as there are no compile-time checks what can you throw)! Please note that in the _whole_ stacktrace, there is no method declared to throw a checked exception. Even the method which have actually thrown the exception (sun.awt.datatransfer.ClipboardTransferable.getClipboardFormats) is declared to throw nothing, but it is a native method. This is clearly bug in the JDK implementation and we can't work it around (no NB code involved after the second event look is started with the modal dialog, BTW: did the dialog have collapsed or stopped being modal). Reference: BugParade #4655996, it is already fixed in hopper according to the BugParade Resolving as INVALID because even the editor part should NOT be fixed (although it is already) as it shall NOT happen and it is generally wrong to catch something not declared to be thrown.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.