Community
Participate
Working Groups
Typing F2 followed by ESC in the Project Explorer very fast can kill Eclipse (at least on Windows 10). Unsaved changes will be lost (no "Save Resource(s)" is shown). Reproducible with the Eclipse SDK and with the Java IDE package (both 2019-09 RC1): eclipse-SDK-4.13RC1-win32-x86_64.zip Version: 2019-09 (4.13) Build id: I20190828-1800 20190905-1130_eclipse-java-2019-09-RC1-win32.win32.x86_64.zip Version: 2019-09 RC1 (4.13.0RC1) Build id: 20190905-1130 Inline rename: see bug 548877
Holger, by "kill" do you mean crash or indefinite hanging? In first case, please provide crash file (start Eclipse on command line to see it), in second case - thread dump.
Created attachment 279802 [details] Java 11 HotSpot crash file (In reply to Andrey Loskutov from comment #1) > Holger, by "kill" do you mean crash or indefinite hanging? In first case, > please provide crash file (start Eclipse on command line to see it), in > second case - thread dump. The Java VM is crashing. See attached crash file.
(In reply to Holger Voormann from comment #2) > Created attachment 279802 [details] > Java 11 HotSpot crash file > > (In reply to Andrey Loskutov from comment #1) > > The Java VM is crashing. See attached crash file. Thanks, below the relevant part. Current thread (0x0000000002903800): JavaThread "main" [_thread_in_native, id=14076, stack(0x00000000006c0000,0x00000000007c0000)] Stack: [0x00000000006c0000,0x00000000007c0000], sp=0x00000000007b7f50, free space=991k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [Oleacc.dll+0xd0fc] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 4109 org.eclipse.swt.internal.win32.OS.CallWindowProc(JJIJJ)J (0 bytes) @ 0x0000000012ea7496 [0x0000000012ea7440+0x0000000000000056] j org.eclipse.swt.widgets.Text.callWindowProc(JIJJ)J+1111 J 6047 c1 org.eclipse.swt.widgets.Control.windowProc(JIJJ)J (1980 bytes) @ 0x000000000c51274c [0x000000000c50b500+0x000000000000724c] j org.eclipse.swt.widgets.Text.windowProc(JIJJ)J+395 J 5105 c2 org.eclipse.swt.widgets.Display.windowProc(JJJJ)J (108 bytes) @ 0x0000000012fca1d4 [0x0000000012fca040+0x0000000000000194] v ~StubRoutines::call_stub J 4109 org.eclipse.swt.internal.win32.OS.CallWindowProc(JJIJJ)J (0 bytes) @ 0x0000000012ea7496 [0x0000000012ea7440+0x0000000000000056] j org.eclipse.swt.widgets.Text.callWindowProc(JIJJ)J+1111 j org.eclipse.swt.widgets.Widget.wmSetFocus(JJJ)Lorg/eclipse/swt/internal/win32/LRESULT;+7 j org.eclipse.swt.widgets.Control.WM_SETFOCUS(JJ)Lorg/eclipse/swt/internal/win32/LRESULT;+7 J 6047 c1 org.eclipse.swt.widgets.Control.windowProc(JIJJ)J (1980 bytes) @ 0x000000000c51213c [0x000000000c50b500+0x0000000000006c3c] j org.eclipse.swt.widgets.Text.windowProc(JIJJ)J+395 J 5105 c2 org.eclipse.swt.widgets.Display.windowProc(JJJJ)J (108 bytes) @ 0x0000000012fca0b0 [0x0000000012fca040+0x0000000000000070] v ~StubRoutines::call_stub j org.eclipse.swt.internal.win32.OS.SetFocus(J)J+0 j org.eclipse.swt.widgets.Control.forceFocus()Z+69 j org.eclipse.swt.widgets.Control.setFocus()Z+18 j org.eclipse.ui.actions.RenameResourceAction.queryNewResourceNameInline(Lorg/eclipse/core/resources/IResource;)V+155 j org.eclipse.ui.actions.RenameResourceAction.runWithInlineEditor()V+16 j org.eclipse.ui.actions.RenameResourceAction.run()V+27 j org.eclipse.ui.actions.BaseSelectionListenerAction.runWithEvent(Lorg/eclipse/swt/widgets/Event;)V+6 j org.eclipse.jface.commands.ActionHandler.execute(Lorg/eclipse/core/commands/ExecutionEvent;)Ljava/lang/Object;+73 j org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(Lorg/eclipse/e4/core/contexts/IEclipseContext;Ljava/util/Map;Lorg/eclipse/swt/widgets/Event;Lorg/eclipse/core/expressions/IEvaluationContext;)Ljava/lang/Object;+123 v ~StubRoutines::call_stub J 4055 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@11.0.1 (0 bytes) @ 0x0000000012e9dbbf [0x0000000012e9db40+0x000000000000007f] J 4054 c1 jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@11.0.1 (104 bytes) @ 0x000000000c0151bc [0x000000000c0145c0+0x0000000000000bfc] J 933 c1 jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@11.0.1 (10 bytes) @ 0x000000000b9308dc [0x000000000b9307e0+0x00000000000000fc] J 4145 c1 org.eclipse.e4.core.internal.di.MethodRequestor.execute()Ljava/lang/Object; (189 bytes) @ 0x000000000c05cf7c [0x000000000c05bec0+0x00000000000010bc] j org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(Ljava/lang/Object;Ljava/lang/Class;Ljava/lang/Class;Ljava/lang/Object;Lorg/eclipse/e4/core/di/suppliers/PrimaryObjectSupplier;Lorg/eclipse/e4/core/di/suppliers/PrimaryObjectSupplier;ZZZ)Ljava/lang/Object;+115 j org.eclipse.e4.core.internal.di.InjectorImpl.invoke(Ljava/lang/Object;Ljava/lang/Class;Ljava/lang/Object;Lorg/eclipse/e4/core/di/suppliers/PrimaryObjectSupplier;Lorg/eclipse/e4/core/di/suppliers/PrimaryObjectSupplier;)Ljava/lang/Object;+15 j org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(Ljava/lang/Object;Ljava/lang/Class;Lorg/eclipse/e4/core/contexts/IEclipseContext;Lorg/eclipse/e4/core/contexts/IEclipseContext;Ljava/lang/Object;)Ljava/lang/Object;+29 j org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(Lorg/eclipse/core/commands/ExecutionEvent;)Ljava/lang/Object;+94 j org.eclipse.core.commands.Command.executeWithChecks(Lorg/eclipse/core/commands/ExecutionEvent;)Ljava/lang/Object;+164 j org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+21 j org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(Lorg/eclipse/core/commands/ParameterizedCommand;Lorg/eclipse/e4/core/contexts/IEclipseContext;)Ljava/lang/Object;+38 j org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(Lorg/eclipse/core/commands/ParameterizedCommand;Lorg/eclipse/swt/widgets/Event;)Z+148 j org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(Ljava/util/List;Lorg/eclipse/swt/widgets/Event;)Z+167 j org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(Ljava/util/List;Lorg/eclipse/swt/widgets/Event;)V+14 j org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(Lorg/eclipse/swt/widgets/Event;)V+219 j org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$2(Lorg/eclipse/e4/ui/bindings/keys/KeyBindingDispatcher;Lorg/eclipse/swt/widgets/Event;)V+2 j org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(Lorg/eclipse/swt/widgets/Event;)V+35 J 6206 c2 org.eclipse.swt.widgets.EventTable.sendEvent(Lorg/eclipse/swt/widgets/Event;)V (592 bytes) @ 0x00000000130a1058 [0x00000000130a0fc0+0x0000000000000098] J 6093 c2 org.eclipse.swt.widgets.Display.filterEvent(Lorg/eclipse/swt/widgets/Event;)Z (43 bytes) @ 0x0000000013081a5c [0x0000000013081900+0x000000000000015c] J 5220 c1 org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;Z)V (88 bytes) @ 0x000000000c30cd74 [0x000000000c30c860+0x0000000000000514] j org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;)V+4 j org.eclipse.swt.widgets.Widget.sendKeyEvent(IIJJLorg/eclipse/swt/widgets/Event;)Z+4 j org.eclipse.swt.widgets.Widget.sendKeyEvent(IIJJ)Z+32 j org.eclipse.swt.widgets.Widget.wmKeyDown(JJJ)Lorg/eclipse/swt/internal/win32/LRESULT;+643 j org.eclipse.swt.widgets.Control.WM_KEYDOWN(JJ)Lorg/eclipse/swt/internal/win32/LRESULT;+7 j org.eclipse.swt.widgets.Tree.WM_KEYDOWN(JJ)Lorg/eclipse/swt/internal/win32/LRESULT;+3 J 6047 c1 org.eclipse.swt.widgets.Control.windowProc(JIJJ)J (1980 bytes) @ 0x000000000c510184 [0x000000000c50b500+0x0000000000004c84] J 5069 c1 org.eclipse.swt.widgets.Tree.windowProc(JIJJ)J (1676 bytes) @ 0x000000000c2a01dc [0x000000000c29c940+0x000000000000389c] J 5105 c2 org.eclipse.swt.widgets.Display.windowProc(JJJJ)J (108 bytes) @ 0x0000000012fca0b0 [0x0000000012fca040+0x0000000000000070] v ~StubRoutines::call_stub J 6041 org.eclipse.swt.internal.win32.OS.DispatchMessage(Lorg/eclipse/swt/internal/win32/MSG;)J (0 bytes) @ 0x000000001307eb12 [0x000000001307eac0+0x0000000000000052] J 5993 c1 org.eclipse.swt.widgets.Display.readAndDispatch()Z (94 bytes) @ 0x000000000c4ec664 [0x000000000c4ec020+0x0000000000000644]
(In reply to Andrey Loskutov from comment #3) This looks like an issue of SWT in Windows (in the native C code, not in Java) and cannot be reproduced on Linux and macOS, right? On Windows 10 on my machine the Java VM crashes after 1 to 12 attempts. Therefore, I move the bug from Platform IDE to Platform SWT.
Thanks for CC'ing me, I'm indeed interested in native crashes. Will look into it once I finish the other tasks, hopefully this week.
This issue also occurs on my Windows 10 computer (sometimes after a delay), when doing a normal inline renaming, without hitting ESC.
I've tested it on two more computers. On another Windows 7 computer with the same Eclipse IDE and JRE it did not crash, but on another Windows 10 computer it did. The issue seems to occur on Windows 10 independent of the CPU/GPU, of the Java VM and of the IDE package.
The Eclipse IDE 2019-09 RC2 also crashes when in the (Git) History view the Find Toolbar will be hidden and then enabled again. In contrast, the Java VM does not crash in Eclipse 2019-06 and 2019-03 on hiding/showing the Find Toolbar.
(In reply to Holger Voormann from comment #8) > The Eclipse IDE 2019-09 RC2 also crashes when in the (Git) History view the > Find Toolbar will be hidden and then enabled again. Is this related to the inline rename or a separate issue?
> Typing F2 followed by ESC in the Project Explorer very fast can kill Eclipse Does it also crash when you use the context menu?
(In reply to Dani Megert from comment #9) > (In reply to Holger Voormann from comment #8) > > The Eclipse IDE 2019-09 RC2 also crashes when in the (Git) History view the > > Find Toolbar will be hidden and then enabled again. > Is this related to the inline rename or a separate issue? With 'M2' and Windpws 10, I see a disturbing number (one a week) of Eclipse crashes but have never been able to pin the problem down to a repro or even Bug report. From recollection they are more likely to be GIT rather than Package Explorer related. I see OS freezes in Firefox so Windows 10 may just be bad...
(In reply to Dani Megert from comment #9) > Is this related to the inline rename or a separate issue? I don't know if hiding/showing the Git History Find Toolbar is the same issue. From the user's point of view, it looks the same: Eclipse crashes and unsaved data will be lost. (In reply to Dani Megert from comment #10) > Does it also crash when you use the context menu? Yes, it crashes independent if inline renaming is triggered via right-click menu or via F2. (In reply to Ed Willink from comment #11) > I see OS freezes in Firefox so Windows 10 may just be bad… Hiding and unhiding the Git History Find Toolbar on the same computer with other Eclipse versions does not crash Eclipse. Because the inline renaming is new, I can't test it with previous versions.
(In reply to Holger Voormann from comment #12) > (In reply to Dani Megert from comment #9) > > Is this related to the inline rename or a separate issue? > I don't know if hiding/showing the Git History Find Toolbar is the same > issue. From the user's point of view, it looks the same: Eclipse crashes and > unsaved data will be lost. Something with toolbars has changed. The code in EGit didn't change at all in this area. On 2019-09 M3 on Mac OS X I get an NPE: 1. Start Eclipse 2. Show some repo in history view. (My history view comes up with the search field visible.) 3. Close search field by clicking on the "magnifier" icon. 4. Click on the magnifier again to open the text input again. Search bar doesn't open (it's createControl is never called.) 5. Click on the magnifier icon again. Results in an NPE because the control was never created. At least on Mac, Eclipse doesn't crash. But toggling this dynamic toolbar contribution is definitely non-functional in 2019-09.
(In reply to Thomas Wolf from comment #13) > At least on Mac, Eclipse doesn't crash. But toggling this dynamic toolbar > contribution is definitely non-functional in 2019-09. I also can't tell where the focus goes when I Esc from the inline rename, on Mac.
I tested the Platform Runtime binaries of the Integration Builds with EGit 5.4.2 by hitting a few times the Show/Hide Find Toolbar button in the (Git) History view: eclipse-platform-I20190624-1800-win32-x86_64.zip works fine eclipse-platform-I20190701-1805-win32-x86_64.zip is crashing (and also all of three later builds I tested crash after the Find Toolbar is not shown again as described by Thomas in comment 13)
(In reply to Holger Voormann from comment #15) > I tested the Platform Runtime binaries of the Integration Builds with EGit > 5.4.2 by hitting a few times the Show/Hide Find Toolbar button in the (Git) > History view: > > eclipse-platform-I20190624-1800-win32-x86_64.zip works fine > > eclipse-platform-I20190701-1805-win32-x86_64.zip is crashing > (and also all of three later builds I tested crash after the Find Toolbar is > not shown again as described by Thomas in comment 13) I don't think the find toolbar is the same problem as the inline rename. In any case, on Mac the find toolbar works in Eclipse SDK I20190708-1800 but fails in Eclipse SDK I20190715-1800. The find toolbar NPE is caused by https://git.eclipse.org/r/#/c/145577/ . When I revert that, the find toolbar works again. Seems to be a problem with visibility. The SearchBar item from the history view gets wrapped in a SubContributionItem. On a working eclipse, we have SubContributionItem.visible = true and SearchBar.visible = true when it should be shown. On a broken Eclipse, we have SubContributionItem.visible = false and SearchBar.visible = true.
(In reply to Thomas Wolf from comment #16) > I don't think the find toolbar is the same problem as the inline rename. Created bug 551067 for the find toolbar.
(In reply to Nitin Dahyabhai from comment #14) > I also can't tell where the focus goes when I Esc from the inline rename, on > Mac. True, and the selection is not properly redrawn (also on Mac). The part of the line before the file icon remains blue (active selection), the rest is gray. Scrolling the project explorer a little horizontally fixes the redraw of the selection (all gray then).
An observation that might be helpful: In contrast to an inline rename in the Project Explorer that leads to a crash in many cases after a short delay (about 5 seconds), inline renaming in the Navigator works for me. In the Navigator I can crash Eclipse only with fast sequences of F2 followed by ESC. Is there anyone where inline renaming in the Project Explorer doesn't crash Eclipse on Windows 10? And what about Windows 8?
(In reply to Holger Voormann from comment #6) > This issue also occurs on my Windows 10 computer (sometimes after a delay), > when doing a normal inline renaming, without hitting ESC. Can someone else reproduce this?
(In reply to Dani Megert from comment #20) > Can someone else reproduce this? Noopur and I are able to reproduce the crash in following scenarios on Windows 10 (using JRE 11 & JRE 8): Note: Any file type with in-line rename support is crashing, e.g. foo.txt 1. In old Navigator view: - 'F2' followed by 'Esc' and repeating this few times. - 'F2' followed by in-line renaming(change the file name without pressing Enter), then pressing 'Esc' and then switching focus to another file. 2. In Project Explorer: - 'F2' followed by 'Esc' and repeating this few times. - 'F2' followed by in-line renaming and press Enter. And repeat this renaming process few times. - 'F2' followed by in-line renaming and press Enter. Now switch focus after successful rename.
(In reply to Niraj Modi from comment #21) > 2. In Project Explorer: > - 'F2' followed by in-line renaming and press Enter. Now switch focus after > successful rename. This scenario is indeed critical. Please also see https://www.eclipse.org/lists/eclipse-pmc/msg03754.html.
New Gerrit change created: https://git.eclipse.org/r/149575
(In reply to Niraj Modi from comment #21) > (In reply to Dani Megert from comment #20) > > Can someone else reproduce this? > > Noopur and I are able to reproduce the crash in following scenarios on > Windows 10 (using JRE 11 & JRE 8): > Note: Any file type with in-line rename support is crashing, e.g. foo.txt > 1. In old Navigator view: > - 'F2' followed by 'Esc' and repeating this few times. > - 'F2' followed by in-line renaming(change the file name without pressing > Enter), then pressing 'Esc' and then switching focus to another file. > > 2. In Project Explorer: > - 'F2' followed by 'Esc' and repeating this few times. > - 'F2' followed by in-line renaming and press Enter. And repeat this > renaming process few times. > - 'F2' followed by in-line renaming and press Enter. Now switch focus after > successful rename. Just clarifying on what switch-focus means in above context: Switching focus to an editor might crash depending on the editor kind. If it does not crash, then switching back to Project Explorer leads to crash.
Can be reproduced very easily if Application Verifier is used. You guys need to start using it more often ;) Steps: 1) Set up Application Verifier as explained here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=543747#c57 2) Open Eclipse's Project Explorer 3) Select .txt file 4) Press F2 5) Press Esc This crash is already known as '(Type C)' crash in Bug 543747. While Bug 543747 is triggered by RDP, the core problem is a bug in Windows IME API, which manifests in various ways.
Clarification: Bug 543747 was reported as crash after RDP, but the underlying issue is bigger. While working on it, I discovered more crashes (each of them is merely a new symptom of the same problem), where '(Type C)' specifically doesn't require RDP at all and happens when a Composite with a Text inside is disposed while parent still lives.
In the 4.13 maintenance branch and in the master branch the inline renaming in the Project Explorer has been reverted: - https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a7975082f940e577c1ebb82439ba61d3b7e31673 - https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c99322eec70b19200e9b8dbc9e45f2b25e751fdb Eclipse 4.13RC2a contains this change: https://download.eclipse.org/eclipse/downloads/drops4/S-4.13RC2a-201909161045/ In the Project Explorer and in the Navigator, the renaming no longer happens inline, but via dialogs which is safe. With the Git History Find Toolbar it is still possible to crash Eclipse: by hiding it or by pressing ESC inside the Find Toolbar.
(In reply to Holger Voormann from comment #27) > With the Git History Find Toolbar it is still possible to crash Eclipse: by > hiding it or by pressing ESC inside the Find Toolbar. Tracked by bug 551067.
(In reply to Alexandr Miloslavskiy from comment #26) > Clarification: Bug 543747 was reported as crash after RDP, but the > underlying issue is bigger. While working on it, I discovered more crashes > (each of them is merely a new symptom of the same problem), where '(Type C)' > specifically doesn't require RDP at all and happens when a Composite with a > Text inside is disposed while parent still lives. That's interesting. Could you please create a dedicated ticket for this issue (without RDP)?
Underlying problem is the same, so I would rather not multiply bugs for it.
(In reply to Alexandr Miloslavskiy from comment #30) > Underlying problem is the same, so I would rather not multiply bugs for it. Ok, but can you please retitle the other issue to clarify it's not really a Remote Desktop related issue? It makes it hard to track from bug 548877 otherwise.
It seems that people often find that bug by title, looking for observed crash after RDP, so renaming it also doesn't seem to be a good idea. This bug, however, is a doorway into that other problem.
