Community
Participate
Working Groups
Created from bug 550857: Holger Voormann: bug 550857 comment 8 The Eclipse IDE 2019-09 RC2 also crashes [on Windows] 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. Thomas Wolf: bug 550857 comment 13 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. Thomas Wolf: bug 550857 comment 16 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.
Rolf, can you have a look?
Created attachment 279912 [details] vm crash log On Windows 10 I saw both crash and NPE case, depending on the text field initial visibility. java.lang.NullPointerException at org.eclipse.egit.ui.internal.history.GitHistoryPage$SearchBar.beforeHide(GitHistoryPage.java:1330) at org.eclipse.egit.ui.internal.history.GitHistoryPage$SearchBar.setVisible(GitHistoryPage.java:1343) at org.eclipse.egit.ui.internal.history.GitHistoryPage$GitHistoryPageActions$1.run(GitHistoryPage.java:543) at org.eclipse.jface.action.Action.runWithEvent(Action.java:474) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:580) at org.eclipse.jface.action.ActionContributionItem.lambda$5(ActionContributionItem.java:451) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4173) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3986) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3585) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1049) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:633) Crash message (from attached file): # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffecfa2d8f8, pid=9800, tid=0x0000000000000854 # # JRE version: Java(TM) SE Runtime Environment (8.0_221-b11) (build 1.8.0_221-b11) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [MSCTF.dll+0xd8f8] On Linux only NPE, with same stack as on Windows
(In reply to Andrey Loskutov from comment #2) > On Linux only NPE, with same stack as on Windows In the NPE case, the stack will always be that one. What happens is simple: * Search field is not visible. * User clicks magnifying glass icon. * EGit changes visibility of toolbar contribution and updates toolbar. This step used to create the control for the contribution, but now doesn't. * User doesn't see the search field appear and clicks again. * The contribution item's visiblity is TRUE, so EGit thinks the item exists, its control exists, and it must be hidden. * EGit tries to access the control to remember the last search string. * Control never existed -> NPE. The big problem is that the control never gets created in step 3 because of the visibility mismatch mentioned in comment 0.
Could it be that one of the perf-improvements (delaying stuff) is causing this? The strategy used there was to defer updates and accumulate them which breaks the assumption in Egit code, that things happen in order?
(In reply to Thomas Schindl from comment #4) > Could it be that one of the perf-improvements (delaying stuff) is causing > this? The strategy used there was to defer updates and accumulate them which > breaks the assumption in Egit code, that things happen in order? The control is _never_ created, wait as long as you like. The NPE doesn't occur on trying to show the item, it occurs later on trying to _hide_ it. And reverting https://git.eclipse.org/r/#/c/145577/ fixes the problem reliably for me. So I rather think something with the changed handling of visibility in that change is broken, or that it uncovers an older bug that until now had no effect. Note that the search field is a dynamic contribution item, wrapped by the framework in a SubContributionItem from a SubContributionManager. Maybe reconciling visibility into the E4 model misses out on that?
@Rolf: do you plan to work on this?
I see a similar behavior in the properties view of an Omph setup file. The jvm crashes when switch in between two rows. There is no exception in the .log File but a hs_err_pid3256.log file in the Eclipse install folder. I attached the file.
Created attachment 279988 [details] another vm crash log VM crash occuring after a switching between rows in the properties page table. The occurence seems not to be reproducible but it occurs very often.
Created attachment 279998 [details] video of reproducable eclipse crash I've attached a video of the eclipse crash. This is reproducable for me. It happens every time i do the following steps: - open eclipse workspace - click on search icon in history view (search text field occurs) - click on search icon in history view (search text field disapears) - click on git stagin view - eclipse crashes with system exit -1073740771 It happens with the latest eclipse 2019-09 and latest windows 10 1903 with all updates installed. There is no error dump file or anything else created by java. Windows Event Viewer shows this: ------------------------------------------------------------ Name der fehlerhaften Anwendung: javaw.exe, Version: 11.0.4.0, Zeitstempel: 0x5d2f9f3f Name des fehlerhaften Moduls: MSCTF.dll, Version: 10.0.18362.356, Zeitstempel: 0x1b84914f Ausnahmecode: 0xc000041d Fehleroffset: 0x000000000002ab68 ID des fehlerhaften Prozesses: 0xc83c Startzeit der fehlerhaften Anwendung: 0x01d572bde2131f43 Pfad der fehlerhaften Anwendung: c:\dev\java\jdk-11_openj9\bin\javaw.exe Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\MSCTF.dll Berichtskennung: 00ac6345-b59f-4901-a107-2825ecf8db49 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist: ------------------------------------------------------------ Fehlerbucket 2267245381392226794, Typ 4 Ereignisname: APPCRASH Antwort: Nicht verfügbar CAB-Datei-ID: 0 Problemsignatur: P1: javaw.exe P2: 11.0.4.0 P3: 5d2f9f3f P4: MSCTF.dll P5: 10.0.18362.356 P6: 1b84914f P7: c000041d P8: 000000000002ab68 P9: P10: Angefügte Dateien: \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7C9E.tmp.dmp \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7DD7.tmp.WERInternalMetadata.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7DF8.tmp.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7DF8.tmp.csv \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7E28.tmp.txt Diese Dateien befinden sich möglicherweise hier: Analysesymbol: Es wird erneut nach einer Lösung gesucht: 0 Berichts-ID: 00ac6345-b59f-4901-a107-2825ecf8db49 Berichtstatus: 268435456 Bucket mit Hash: b6d9969cc41d1d132f76dfa9788759ea CAB-Datei-Guid: 0
(In reply to Thomas Wolf from comment #0) > 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. I assume we have two different issues here - NPE and crash. The crash on Windows (that seem to be caused by setting focus on the Text widget) does not disappear after reverting the change from patch https://git.eclipse.org/r/#/c/145577 on ToolBarManagerRenderer. I still get exact same crash dump: Stack: [0x0000002869d00000,0x0000002869e00000], sp=0x0000002869dfa930, free space=1002k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [MSCTF.dll+0x2aca8] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 5809 org.eclipse.swt.internal.win32.OS.CallWindowProc(JJIJJ)J (0 bytes) @ 0x000001e487f49da6 [0x000001e487f49d40+0x0000000000000066] J 11818 c1 org.eclipse.swt.widgets.Text.callWindowProc(JIJJ)J (1170 bytes) @ 0x000001e48098dbc4 [0x000001e48098c160+0x0000000000001a64] j org.eclipse.swt.widgets.Control.windowProc(JIJJ)J+2041 J 11817 c1 org.eclipse.swt.widgets.Text.windowProc(JIJJ)J (465 bytes) @ 0x000001e4806ff2fc [0x000001e4806fe540+0x0000000000000dbc] J 7371 c2 org.eclipse.swt.widgets.Display.windowProc(JJJJ)J (108 bytes) @ 0x000001e4880c6b2c [0x000001e4880c6940+0x00000000000001ec] v ~StubRoutines::call_stub J 5809 org.eclipse.swt.internal.win32.OS.CallWindowProc(JJIJJ)J (0 bytes) @ 0x000001e487f49da6 [0x000001e487f49d40+0x0000000000000066] J 11818 c1 org.eclipse.swt.widgets.Text.callWindowProc(JIJJ)J (1170 bytes) @ 0x000001e48098dbc4 [0x000001e48098c160+0x0000000000001a64] 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 org.eclipse.swt.widgets.Control.windowProc(JIJJ)J+1714 J 11817 c1 org.eclipse.swt.widgets.Text.windowProc(JIJJ)J (465 bytes) @ 0x000001e4806ff2fc [0x000001e4806fe540+0x0000000000000dbc] J 7371 c2 org.eclipse.swt.widgets.Display.windowProc(JJJJ)J (108 bytes) @ 0x000001e4880c69b4 [0x000001e4880c6940+0x0000000000000074] 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.egit.ui.internal.history.FindToolbar.setFocus()Z+4 j org.eclipse.egit.ui.internal.history.GitHistoryPage$SearchBar.setVisible(Z)V+66 j org.eclipse.egit.ui.internal.history.GitHistoryPage$GitHistoryPageActions$1.run()V+45
(In reply to Andrey Loskutov from comment #10) > (In reply to Thomas Wolf from comment #0) > > 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. > > I assume we have two different issues here - NPE and crash. Yep. I've switched SWT to 4.12 and let UI on 4.13 minus patch https://git.eclipse.org/r/#/c/145577/. That does not crash. I've bisected this to: Last good e9369b8add36045f83b2daf7c291697d5ae21ea1 Bad d4322185047c83ff4f7f4c994db4c89a401c73ca So crash on Windows is a regression from bug 543747, patch https://git.eclipse.org/r/144520, commit http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d4322185047c83ff4f7f4c994db4c89a401c73ca Since bug 543747 was reopened already for a different reason, I propose to use this one for tracking the NPE only.
New Gerrit change created: https://git.eclipse.org/r/150709
(In reply to Eclipse Genie from comment #12) > New Gerrit change created: https://git.eclipse.org/r/150709 This fixes NPE's and broken state of the contribution. (In reply to Thomas Wolf from comment #0) > 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. Exact. Previously, the search toolbar was never disposed, so there were no need to re-create it. Now after the patch https://git.eclipse.org/r/#/c/145577/ that properly disposed "removed" toolbar elements, we see that in order to re-create and show our contribution again we should toggle visibility of the "parent" SubContributionItem *too*. Once SubContributionItem updated *before* bars.updateActionBars() call in GitHistoryPage.SearchBar.setVisible(boolean), we do not "slip through" the visibility check in org.eclipse.jface.action.ToolBarManager.update(boolean) line 269-271 for (IContributionItem ci : items) { if (!isChildVisible(ci)) { // false because the SubContributionItem was not updated continue; // we were here, so no new item was created and all is good again. So I assume manipulation of the visibility state of the *wrapped* ControlContribution on the EGit side was never "enough", and worked only as a side effect of not implemented "remove" functionality of the ToolBarManagerRenderer (via bug 378495).
New Gerrit change created: https://git.eclipse.org/r/150713
Gerrit change https://git.eclipse.org/r/150713 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9fc076dd710d6946eed4e3ad20d33f73bde22300
(In reply to Eclipse Genie from comment #15) > Gerrit change https://git.eclipse.org/r/150713 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=9fc076dd710d6946eed4e3ad20d33f73bde22300 For the record: with build I20191007-1800 and this patch merged we don't see NPE'S anymore on toggling EGit "Find" contribution in the History view. Crashes on Windows are now fixed too via reverting changes made in bug 543747.
*** Bug 551907 has been marked as a duplicate of this bug. ***
@Platform UI committers: please check bug 551914. We (me and Thomas) wonder if the solution in https://git.eclipse.org/r/150713 was the "right" one, even if it fixed the current problem. Please comment on bug 551914.
*** Bug 551947 has been marked as a duplicate of this bug. ***
*** Bug 551677 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/150709 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=9e7e288f0489e8f92883d1ac8d419ae87b6d000e
*** Bug 552186 has been marked as a duplicate of this bug. ***
*** Bug 552203 has been marked as a duplicate of this bug. ***
*** Bug 552265 has been marked as a duplicate of this bug. ***
*** Bug 552122 has been marked as a duplicate of this bug. ***
*** Bug 553660 has been marked as a duplicate of this bug. ***
This also lead to a crash with WindowBuilder, 2019-12 works fine again.
*** Bug 553848 has been marked as a duplicate of this bug. ***
*** Bug 552200 has been marked as a duplicate of this bug. ***
*** Bug 559233 has been marked as a duplicate of this bug. ***
*** Bug 559625 has been marked as a duplicate of this bug. ***
*** Bug 552842 has been marked as a duplicate of this bug. ***
