Community
Participate
Working Groups
Launch Eclipse on a PC running Windows 10 Pro and open some Java code editors. Then go to another Windows 10 PC and connect to the first PC via the Microsoft Remote Desktop app. As soon as the connection establishes, Eclipse crashes. This bug appeared also in previous Eclipse versions. -- Configuration Details -- Product: Eclipse IDE 4.10.0.20181214-0600 (org.eclipse.epp.package.java.product)Installed Features: org.eclipse.platform 4.10.0.v20181206-0815
Do you have a crash log?
We are observing the same issue on Windows 10 1809 only. Windows 10 1803 works fine here. We are using Windows 10 Build 17763.292. It does not seem to be related to the RDP Client because it crashes if connecting from Windows 10 and 7. It is also not limited to the latest Eclipse release (2018-12) but happens on older Eclipse versions as well (e.g. Oxygen.3). Eclipse crashes shortly after the Remote Desktop Connection has been established. There is no Information in the Eclipse log and no JVM crash log written. But there is some Information in the Windows Event Log: Fault bucket 1913951043267564157, type 4 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: eclipse.exe P2: 0.0.0.0 P3: 5b995959 P4: MSCTF.dll P5: 10.0.17763.1 P6: 6c634a1d P7: c0000005 P8: 0000000000049f6e P9: P10: Faulting application name: eclipse.exe, version: 0.0.0.0, time stamp: 0x5b995959 Faulting module name: MSCTF.dll, version: 10.0.17763.1, time stamp: 0x6c634a1d Exception code: 0xc0000005 Fault offset: 0x0000000000049f6e Faulting process id: 0x12bc Faulting application start time: 0x01d4b6f0fffbadba Faulting application path: C:\eclipse\eclipse.exe Faulting module path: C:\Windows\System32\MSCTF.dll Report Id: c331c853-99e1-4f4d-b48c-777965ac2db9 Faulting package full name: Faulting package-relative application ID:
I have the same issue. Here my log and diagnostic details: Eclipse SDK Version: 2018-12 (4.10) Build id: I20181206-0815 -- Windows Version Windows 10, Version 1809, Build 17763.253 -- Windows Event Log Faulting application name: eclipse.exe, version: 0.0.0.0, time stamp: 0x5a02bee8 Faulting module name: MSCTF.dll, version: 10.0.17763.1, time stamp: 0x6c634a1d Exception code: 0xc0000005 Fault offset: 0x0000000000049f6e Faulting process id: 0x40e0 Faulting application start time: 0x01d4b3d9308ee16f Faulting application path: C:\dev\eclipse\eclipse-4.7\eclipse.exe Faulting module path: C:\WINDOWS\System32\MSCTF.dll Report Id: 6c840151-6907-4f73-9dc5-ce1798991890 Faulting package full name: Faulting package-relative application ID: Fault bucket 1913951043267564157, type 4 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: eclipse.exe P2: 0.0.0.0 P3: 5b995959 P4: MSCTF.dll P5: 10.0.17763.1 P6: 6c634a1d P7: c0000005 P8: 0000000000049f6e P9: P10: Attached files: \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER3B8D.tmp.dmp \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER40ED.tmp.WERInternalMetadata.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER415B.tmp.xml \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER416B.tmp.csv \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER417C.tmp.txt These files may be available here: \\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_eclipse.exe_a0d7a0649e7ae0c9114eed983882bdf19a83f3d_34b5ab35_1add4784 Analysis symbol: Rechecking for solution: 0 Report Id: 08ef6c86-381f-416b-befe-44fb4e497414 Report Status: 268435456 Hashed bucket: e7c92ce1ac6d5f5f8a8fb8555373927d Cab Guid: 0
Nothing we can do without further details.
(In reply to Dani Megert from comment #4) > Nothing we can do without further details. Did you try to reproduce this behaviour? It is sufficient to run eclipse on a Windows 10 with actual build 1809. I reproduced it with eclipse versions 4.10, 4.9, 4.8, 4.7 and 4.6. Always the same. When doing a windows remote connection (rdp) to that machine. After at most some seconds the eclipse.exe process is dead. Does your reply mean that [] you are not able to reproduce it? [] your tried to reproduce it but the effect did not happen? [] you tried to reproduce it and it happened but there is no hint what to do now?
Worked for me using Windows 7. Niraj, please try with Windows 10.
info: the windows 10 build version can be found by running winver.exe
We are also experiencing this issue. It appears that a recent windows update has caused this issue, as we do not update our version of eclipse. It affects multiple people on my team. Eclipse version- Version: Oxygen.1a Release (4.7.1a) Build id: 20171005-1200 Windows Version: Version 1809 My Windows Event Log contains an identical error as Ivan's. There is nothing in my {WORKSPACE}/.metadata/.log file at the time of the crash, simply a startups logs when I restarted the application. I do not have the ability to test on another version of Windows. Thanks!
(In reply to Dani Megert from comment #6) > Worked for me using Windows 7. > > Niraj, please try with Windows 10. Works for me too, I am using eclipse from quite some time on Win10 Version 1809 without crash on a virtual box VM.
Thanks for the test Niraj. PS: If i started eclipse from within the remote desktop session then no crash happens when i close rdp and open again. So just to clarify, how exactly was your test process? The only way I can reproduce it is by - initially start up eclipse on the windows 10 1809 device (this is important!) - then lock the machine (windows-L) - start up another windows 10 machine (this may or may not be a 1809) - connect to the former windows 10-1809 using rdp. - crash follows Did you do the test exactly in that manner? Yours Ivan
Same issue here, two cases are known: Host system is running Windows 10 with two displays a) RDP guest is a Macbook with a single display. I am using the latest MS RDP client for mac. b) RDP guest is a notebook running Windows 10 with two displays. The event log entry of the host is basically identical to the one in comment #2.
regarding comment #11: crash happens when Windows RDP client has a single display only.
same issue here with same condition (multiple monitor in ths host and single monitor in RDP client)
Niraj, please try with the steps from comment 11.
Maybe you can reproduce the problem on windows client. I'm using mstsc client on windows (w/ single monitor) to connect windows host (w/ 2 monitors), and have the problem.
(In reply to Joachim Fuchs from comment #11) > Same issue here, two cases are known: > > Host system is running Windows 10 with two displays > > a) RDP guest is a Macbook with a single display. I am using the latest MS > RDP client for mac. > > b) RDP guest is a notebook running Windows 10 with two displays. > > The event log entry of the host is basically identical to the one in comment > #2. Virtual box Win10 VM could be upgraded to Insider Preview version 1809 and there I don't connect using RDP client. But I cannot upgrade my Win10 VM version 1803 to Insider Preview version 1809 to try it out above steps. Few queries: 1. Is the requirement of two displays at any/either end mandatory for this crash ? 2. Is RDP from Macbook really needed ? or can be done from any other Windows7 or Windows10 ? Moving out of 4.11 as the issue is specific to Insider Preview version 1809 only.
Yes, it seems that the crash occurs quite reliable (not 100%) when the connecting client has only a single display running. It does not matter whether it is a mac or windows client.
I was able to reproduce it. Essential steps: 1) Open some Shell with a Text. 2) Set focus to this Text. 3) Close Shell. 4) Connect RDP.
Will continue studying it next week.
We have the same issue in our eclipse based rcp-application based on platform 4.9. It crashes sometimes in MSCTF.dll, Version: 10.0.17763.348 when using Windows Remote Desktop or when running Jubula UI-Tests. We noticed it first time on April, 15th.
From my experience, this issue *never* happened with version 2018-09 running on Windows 7, and now happens 100% of the time with 2019-03 (20190314-1200) running on Windows 10. It doesn't matter what client I connect from - it crashes if I connect from a Windows 10 Surface, Windows 10 laptop or an iPad running the RD Client app. Sometimes it crashes before I've even managed to log in via RD, and other times I log in, I see the Eclipse window in the task bar and then a few seconds later it disappears.
I'm still digging into this - just slowly: had some other things to do, and debugging Windows itself is not too easy. Preliminary results: This is a bug in Windows 10, and SWT's ImmAssociateContext() triggers it somehow.
@Alexandr Are you planning to fix this bug for 4.12? If not, please move the Target Milestone to 4.13.
I'm still working on it, can't really say how long it's going to take. The problem is rather complicated, because I'm debugging Windows without sources, and every time I find something like "this happens because this map has extra item", there's another layer like "this is because another map is wrong".
(In reply to Alexandr Miloslavskiy from comment #24) > I'm still working on it, can't really say how long it's going to take. > > The problem is rather complicated, because I'm debugging Windows without > sources, and every time I find something like "this happens because this map > has extra item", there's another layer like "this is because another map is > wrong". This indicates that a fix might be complicated and/or risky. I'm moving this to 4.13. If you find an easy fix, we can reconsider for 4.12.
In our organisation we use several self developed applications based on Eclipse RCP and several versions of Eclipse IDEs and other IDEs that are based on Eclipse IDEs. We experience the crashes with this applications with a varying degree of reproducibility ranging from ~5% to 100%. Regarding the question, if there is a difference if the RDP-Clients have one or two monitors -> no difference. The crashes are not strictly limited to new RDP-connections to existing console sessions, they also occur with "user switches" at console session level: - login as user "A" at Windows console (keyboard, mouse, display are physically connected to the pc) - start Eclipse RCP based application/IDE in the console session - do a "user switch" (Ctrl-Alt-Del -> Switch user) and login as user "B" - do a "user switch" (Ctrl-Alt-Del -> Switch user) and re-login as user "A" (this opens the disconnected console session) -> the Eclipse RCP based application/IDE crashes The crashes occur with * 3 custom self developed applications based on Eclipse RCP 4.6.3 32 Bit * Eclipse IDE 3.6 32 Bit * Eclipse IDE 4.6.3 64 Bit * Commercial IDE based on Eclipse IDE 3.6.3 64 Bit The applications/IDEs use different JREs (Oracle JRE/IBM JRE/Adopt-OpenJDk) and java versions (1.6/1.7/1.8, 32Bit/64Bit). Windows 10 1809 Build 17763.437 is our initial Windows 10 roll out, we have no comparison to previous Windows 10 versions (Windows 7 works fine).
So the bug triggers when SWT calls ImmAssociateContext. SWT does it to maintain independent per-shell IMM context (default IMM context is per-thread). SWT needs per-shell context ONLY to implement Shell.getImeInputMode/setImeInputMode. It's not needed for custom IME support in StyledText etc. Neither GTK nor Cocoa implement Shell.setImeInputMode. So my proposal is: let's remove Win32 implementation too. Setting input mode at the Shell level is weird to begin with. It should have been a property of a Text field.
Using ImmAssociateContext on Shell is not a problem. Setting it on Text with intermediate parent(s) is what triggers the problem. My current state of investigation: 1) There seems to be a reference counting bug in WINAPI where MSCTF!CCompositeContextAdapter will often contain pointer to already deleted CInputContext 2) Text controls are special because they use MSCTF!CCompositeContextAdapter 3) MSCTF!CCompositeContextAdapter is special in a way that it's not getting cleaned from an internal dictionary, not sure why this decision was made by Microsoft. 4) On top of that, there's a misdesign where when window is destroyed with DestroyWindow, only the window itself or its *immediate* children are removed from internal dictionary All of these combined lead to: 1) Use Text which is not an immediate child to Shell and instead has another intermediate parent 2) MSCTF!CCompositeContextAdapter with a dangling pointer stay in internal dictionary. 3) Connecting RDP iterates over this dictionary and crashes.
I currently plan to investigate it a little bit further and try these potential workarounds: 1) In Widget.dispose, if it's a Text, explicitly call DestroyWindow(). 2) Use same ImmContext for all controls in application and never delete the ImmContext.
Created attachment 278819 [details] Native snippet showing 526758, 543747
New Gerrit change created: https://git.eclipse.org/r/143817
Here's the patch; it also includes test snippet. Anyone willing to review? If someone can test if IME interaction is still good (for example anyone with Chinese/Japanese), this is most welcome!
Some additional notes about workarounds I decided to not take: In Widget.dispose, if it's a Text, explicitly call DestroyWindow() ------------------------------------------------------------------ This still fails to work if Text has input focus. Moving focus can cause side effects in user's application. Use same ImmContext for all controls in application and never delete it ----------------------------------------------------------------------- This could work, because the crash occurs due to leaked item with a dangling pointer to ImmContext. If ImmContext is never deleted, then pointer will never become dangling. However, there're too many usages of ImmContext to analyze if it's safe to do. Contrary to what Nikita Nemkin said in Comment 27, context is inherited from Shell to individual controls, so if affects most code paths that use ImmContext.
(In reply to Alexandr Miloslavskiy from comment #33) > Contrary to what Nikita Nemkin said in Comment > 27, context is inherited from Shell to individual controls, so if affects > most code paths that use ImmContext. Why do you think that those code paths won't work with the default context? The custom context that SWT propagates does nothing. In fact, setImeInputMode is all kinds of broken: * It doesn't work when using global input context (when Win10 option named "Let me use different input method for each app window" is off, which is the default). Only on/off works in this case, not particular modes. * Shells still appear to share input mode. I.e. setImeInputMode(SWT.PHONETIC) in one shell is still in effect when entering text in another shell. Please use the attached snippet to verify: just type "aiu" + Enter into every text box while using Japanese layout. I really want to have setImeInputMode deprecated and replaced with a stub like in other ports. There is a better, actually working way of setting input mode (SetInputScope), but it requires a different API on SWT level.
Created attachment 278903 [details] Shell_setImeInputMode_Test.java
It's hard to predict the consequences of using a single context. For example, Caret.resizeIME() - when it sets location for one Shell, what will happen in other shells? And there're dozens of similar questions. On top of that, I can imagine that one shell can do something and cause a lasting effect in other shells, whereas currently all of them are isolated. Maybe in the end yes, single context should be used, but this change is too massive and I can fix the crash with much smaller patch.
I can confirm that in provided snippet, setImeInputMode() affects other Shell as well. Happens even when the other shell is not using any custom ImmContext at all. However, this problem is outside the scope of this bug (which is JVM crash).
Hi, I have the same problem, however, I have the following observation. Host is running 4 displays on Windows 10, when I remote from my Windows 10 laptop with 1 display, if eclipse was left on the primary display on the host, it survives. However, if it was left on other non-primary display, eclipse crashes shortly after remote login. Hope this helps. -Alex
Sorry, also note that an SWT app I wrote survives even when left on non-primary screen, so it doesn't seem to affect other java/swt apps...
New Gerrit change created: https://git.eclipse.org/r/144520
Gerrit change https://git.eclipse.org/r/144520 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d4322185047c83ff4f7f4c994db4c89a401c73ca
Gerrit change https://git.eclipse.org/r/143817 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9f2b0cad8e01a8a5de20f04f9a1a50003f727ce0
Interesting bug fix. Thank you both Alexandr for the detailed analysis of this problem and Nikita for getting to the final fix, resolving now.
Hi, can someone tell me when we're getting the fix? Many many thanks!
(In reply to Andrew Yan from comment #44) > Hi, can someone tell me when we're getting the fix? Many many thanks! Bug fix has gone into 4.13 M1 milestone which will be out by July 12, 2019 Until then try latest I-Build I20190627-1800 or above: https://download.eclipse.org/eclipse/downloads/
Verified using IBuild I20190708-1800: old commit e9369b8a - test snippet crashes I20190708-1800 - test snippet doesn't crash
Reopening for back-port to 4.11+, will share a gerrit shortly.
New Gerrit change created: https://git.eclipse.org/r/146080
Gerrit change https://git.eclipse.org/r/146080 was merged to [R4_11_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=4228a22a266df023447f94dd71632920d3bda8c6
Also back-porting to R4_6_maintenance, shortly.
New Gerrit change created: https://git.eclipse.org/r/146082
Gerrit change https://git.eclipse.org/r/146082 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=36ea6466a2fdbf5a5d827af2b4fbf858ced30c5b
Fix back-ported to 'R4_11_maintenance' and 'R4_6_maintenance branches', resolving.
How to these maintenance backports gets consumed by public users? Is it possible to download a patched version of 2019-06? Or is the next version available for download 2019-09?
(In reply to Scott Cameron from comment #54) > Or is the next version available for download 2019-09? Or use 2019-09 M1 build which is scheduled for this Friday.
Created attachment 279400 [details] Tests with/without patches -> crashes Hello The patch of org.eclipse.swt/Eclipse SWT/win32:org.eclipse.swt.widgets.Control.java doesn't work in our use cases/test: Reference applications: 1a) "Eclipse IDE for Java EE Developers" 4.6.3 64Bit + many other features/plugins AdoptOpenJDK 8u212-b04 2a) eclipse-SDK-4.12-win32-x86_64 AdoptOpenJDK 8u212-b04 3a) custom in house application (sorry, but not open source) based on Eclipse RCP 4.6.3 32 Bit IBM JRE 1.8 Patched applications: 1b) = 1a + Update package "E4 RCP Patch (bugzillas 522624,502711,475640,547754,541638,543747) 1.0.7 org.eclipse.e4.rcp.R463patch.feature.group", thanks to IBM/Niraj Modi AdoptOpenJDK 8u212-b04 2b) eclipse-SDK-4.13M1-win32-x86_64 AdoptOpenJDK 8u212-b04 3b) 3a with patched org.eclipse.swt.widgets.Control IBM JRE 1.8 Test with custom in house application (3a,3b): * Windows 10 1809 LTS console session * start application if application is initialized and waiting for the user to do something, connect via RDP to the session => application crashes with 100% certainty IDE-tests (1a,2a,1b,2b): * Windows 10 1809 LTS console session * Start IDE, open a new _empty_ workspace * import java project (attachment) * launch this java project/application * in the console view of the launched application, output is emitted -> connect via RDP to the session => IDE crashes (no difference with or without patch) with high probability the timing of the actions may affect the crash probability :-( The instructions for the IDE tests may seem weird, but this is my best effort for reproducible results :-(
I confirm the problem using latest 4.13 [1]. The crash signature is the same as before. I'll investigate it further. @Bodo, thanks for providing steps! So far I was able to reduce steps to these: 1) Enable Application Verifier as described below. 2) Start Eclipse. 3) 'File | Open Projects from filesystem'. 4) Click 'Directory...' and select any directory. 5) Click 'Cancel' to exit 'Open Projects from filesystem'. 6) Open Task Manager, 'Users' page, right-click yourself, select 'Disconnect'. Application Verifier -------------------- 1) Install Application Verifier: a) Download https://go.microsoft.com/fwlink/p/?LinkID=2033908 b) Install it, selecting Application Verifier. Other components are not required. 2) Configure Application Verifier a) Run "Application Verifier (X64)" from Start menu. b) Use File | Add application... to add eclipse.exe. Add java.exe if your Eclipse's process is java.exe. c) On the right pane, make sure that only 'Basics/Heaps' is selected. Otherwise, Eclipse will not start at all. d) Click "Save". You can close Application Verifier now, it will be active until you remove the settings. Restart Eclipse once. 3) Reproduce the problem Eclipse will run slower and consume more RAM, this is expected. When the crash occurs, collect crash log and new *.mdmp file from same folder. 4) Disable Application Verifier There's no need to disable it if you're ready to tolerate the slowness. Go to Application Verifier again and delete eclipse.exe from the list. Click Save. There's no need to uninstall Application Verifier, but you can do that if you like. -------------------- [1] https://download.eclipse.org/eclipse/downloads/drops4/S-4.13M1-201907111805/
When running under application verifier, the application does not crash/exit. I will do more testing on Sunday.
New Gerrit change created: https://git.eclipse.org/r/147074
I was able to reduce the Eclipse crash to a snippet that reproduces it. This is not a patch yet.
What can I do to help? I was not able to make a consistent test, but now I see there is a manual test in git.
@Jason now it's about debugging and finding a workaround. I will continue investigating it tomorrow.
I hope this is helpful... I applied the fix of the Control.java in the swt fragment. But eclipse still crashes when starting in one windows 10 and then acessing it from another windows 10 with RDP. Based on your very good description (thanks!) I attached ApplicationVverifier to eclipse.exe and started Windows debugger. In ApplicationVverifier i checked x Handles x Heaps x Leak eclipse then just seems not to start, but when constantly clicking F5 (Run/Continue) in the debugger it finally comes up. The reason why it constantly breaks/continues is a lot of access violation exceptions. I don't know if these are false positives or in fact a source of issues. Attached the command log and screens of windows debugger and appverifier.
Created attachment 279507 [details] (Ivan) Application Verifier Screen
Created attachment 279508 [details] (Ivan) Windows Debugger Screen
Created attachment 279509 [details] (Ivan) Windows Debugger log
Ivan, the first-chance access violations you see are normal, JVM uses them for internal operation. I have to use a rather complicated WinDBG script to filter them out. The simplest way of debugging Eclipse with WinDBG is to use "sxn av" WinDBG command. This will skip ALL first-chance exceptions. Second-chance exceptions will still break into debugger.
Aha thanks a lot, yes, that works fine.
I'm still evaluating workarounds. I currently have two in mind, but both look like an overkill to me. The better one is to use 'release(true)' in 'Composite.releaseChildren' for children that are also Composites. This helps Windows remember to clean things up, preventing having stale pointers around, which in turn prevents the crash. Will continue on Monday.
While trying to implement workaround, I ran into yet another variation of the crash, test snippet is in https://git.eclipse.org/r/c/147074/ This new variation is worse then 3 previous. First 3 were caused by Windows bug where it keeps stale pointer to context that SWT correctly destroys with 'ImmDestroyContext' when noone should be using it. The new crash ("Type C" in snippet) will crash even without 'ImmDestroyContext'. This defeats various potential workarounds. For some reason I wasn't able to reproduce this crash in a native snippet. It seems that SWT does something to trigger it, but I wasn't able to figure what is this. I even reduced the whole 'Text' class to just a few lines of code, but it still crashes in SWT. I won't be able to work on this until September.
(In reply to Alexandr Miloslavskiy from comment #70) > While trying to implement workaround, I ran into yet another variation of > the crash, test snippet is in https://git.eclipse.org/r/c/147074/ > > This new variation is worse then 3 previous. First 3 were caused by Windows > bug where it keeps stale pointer to context that SWT correctly destroys with > 'ImmDestroyContext' when noone should be using it. > > The new crash ("Type C" in snippet) will crash even without > 'ImmDestroyContext'. This defeats various potential workarounds. > > For some reason I wasn't able to reproduce this crash in a native snippet. > It seems that SWT does something to trigger it, but I wasn't able to figure > what is this. I even reduced the whole 'Text' class to just a few lines of > code, but it still crashes in SWT. > > I won't be able to work on this until September. Thanks Alexandr, for the investigation and SWT test snippet. Quick question: Does any of the workarounds you tried reduce/fix the possibility/frequency of this crash with Eclipse ? The reason why am checking on this is, at times the SWT test snippet may be going into corner-case scenarios where as in Eclipse we don't have that code coming into picture. In such case we can try to stabilize Eclipse and SWT test case can be dealt separately.
(In reply to Alexandr Miloslavskiy from comment #70) > While trying to implement workaround, I ran into yet another variation of > the crash, test snippet is in https://git.eclipse.org/r/c/147074/ > > I won't be able to work on this until September. Hi Nikita, Will you be able to take this investigation forward ?
Crashes shown by these test snippet buttons are definitely present in Eclipse: * 'Reproduce crash 526758' * 'Reproduce crash 543747 (Type A)' * 'Reproduce crash 543747 (Type B)' As for the new button '(Type C)', I don't know if Eclipse does that or not. These are the workarounds I had in mind: * Explicitly destroy Composites - works in native snippet; leads to '(Type C)' crash in SWT. * Cache context instead of destroying them with 'ImmDestroyContext', reuse cached instead of creating new - doesn't solve '(Type C)', can have unwanted side effects because cached context could have some settings from the old use. * Don't 'ImmDestroyContext' at all - doesn't solve '(Type C)', will leak memory per every Shell created. * Disable whole Imm context machinery if user doesn't have IME capable keyboard layouts - will not solve the problem for those users, will require some work to implement. * Only enable Imm machinery on first use - I barely understand IME workflows and can't predict problems here.
* Rework SWT to only ever use one Imm context for everything - this is what Nikita previously suggested. Doesn't solve '(Type C)', and again I don't understand IME workflows so for me it's too much effort, unless this is the only way.
(In reply to Alexandr Miloslavskiy from comment #73) > Crashes shown by these test snippet buttons are definitely present in > Eclipse: > * 'Reproduce crash 526758' > * 'Reproduce crash 543747 (Type A)' > * 'Reproduce crash 543747 (Type B)' > > As for the new button '(Type C)', I don't know if Eclipse does that or not. Fixing/Workaround 'Type B' in your dev workspace and testing Eclipse as self-hosted shall confirm on above point. Also if 'Type C' scenario is rare then 'Type B', then we can take a call to fix 'Type B' for now which will eventually make Eclipse less prone to Crash. What do you think ?
Hi Alexandr, Any thoughts on comment 75 ? (In reply to Alexandr Miloslavskiy from comment #70) > While trying to implement workaround, I ran into yet another variation of > the crash, test snippet is in https://git.eclipse.org/r/c/147074/ > > This new variation is worse then 3 previous. First 3 were caused by Windows > bug where it keeps stale pointer to context that SWT correctly destroys with > 'ImmDestroyContext' when noone should be using it. Regarding the Windows bug you mentioned where it keeps the stale pointer: - Now we have a contact point in Microsoft who is open to help/fix this issue. Appreciate if you could share more details on the exact problem statement that we could share with Microsoft team to work-on and investigate. Thanks!
(In reply to Niraj Modi from comment #76) > Hi Alexandr, > Any thoughts on comment 75 ? (In reply to Alexandr Miloslavskiy from comment #70) > I won't be able to work on this until September. (In reply to Niraj Modi from comment #76) > Appreciate if you could share more details on the exact problem statement > that we could share with Microsoft team to work-on and investigate. Thanks! I already sent a bug report to Microsoft, including native snippet to reproduce, but _of course_ it was ignored. Who in the world might want a bug report with repro snippet? I'll find report link once back to office.
(In reply to Alexandr Miloslavskiy from comment #77) > (In reply to Niraj Modi from comment #76) > > Hi Alexandr, > > Any thoughts on comment 75 ? > > (In reply to Alexandr Miloslavskiy from comment #70) > > I won't be able to work on this until September. Sure, was just checking after seeing some of your bugzilla communications. > (In reply to Niraj Modi from comment #76) > > Appreciate if you could share more details on the exact problem statement > > that we could share with Microsoft team to work-on and investigate. Thanks! > > I already sent a bug report to Microsoft, including native snippet to > reproduce, but _of course_ it was ignored. Who in the world might want a bug > report with repro snippet? I'll find report link once back to office. Yes, that should help. Once you are back we will also reply/share the micro-soft bug report link on below discussion thread initiated from Microsoft: https://www.eclipse.org/lists/platform-dev/msg01818.html For now moving this bug to 4.14 for further investigation. Thanks!
(In reply to Alexandr Miloslavskiy from comment #77) > (In reply to Niraj Modi from comment #76) > > Hi Alexandr, > > Any thoughts on comment 75 ? > > (In reply to Alexandr Miloslavskiy from comment #70) > > I won't be able to work on this until September. > > > (In reply to Niraj Modi from comment #76) > > Appreciate if you could share more details on the exact problem statement > > that we could share with Microsoft team to work-on and investigate. Thanks! > > I already sent a bug report to Microsoft, including native snippet to > reproduce, but _of course_ it was ignored. Who in the world might want a bug > report with repro snippet? I'll find report link once back to office. Hi Alexandr, I sent you an email regarding this issue. We currently have a case open with Microsoft and would be willing to work together to solve it. Please let me know when you're available or if you have anyone else in mind that could assist. Thank you!
(In reply to Sean Roark from comment #79) > (In reply to Alexandr Miloslavskiy from comment #77) > > (In reply to Niraj Modi from comment #76) > > > Hi Alexandr, > > > Any thoughts on comment 75 ? > > > > (In reply to Alexandr Miloslavskiy from comment #70) > > > I won't be able to work on this until September. > > > > > > (In reply to Niraj Modi from comment #76) > > > Appreciate if you could share more details on the exact problem statement > > > that we could share with Microsoft team to work-on and investigate. Thanks! > > > > I already sent a bug report to Microsoft, including native snippet to > > reproduce, but _of course_ it was ignored. Who in the world might want a bug > > report with repro snippet? I'll find report link once back to office. > > Hi Alexandr, > > I sent you an email regarding this issue. We currently have a case open with > Microsoft and would be willing to work together to solve it. Please let me > know when you're available or if you have anyone else in mind that could > assist. Thank you! Hi @Sean Can you please point us to the open case with Microsoft so that the general people are aware of the changes and follow the case.
The bug report I sent to Microsoft: https://aka.ms/AA598rd Remember that you need to be logged in (inside Feedback Hub application on Win10) to see it.
(In reply to Alexandr Miloslavskiy from comment #81) > The bug report I sent to Microsoft: https://aka.ms/AA598rd > Remember that you need to be logged in (inside Feedback Hub application on > Win10) to see it. Thanks Alexandr. Up-voted and shared it with Microsoft support team contact: https://www.eclipse.org/lists/platform-dev/msg01876.html
We are observing the same issue on Windows 10 1809 and it happen for RDP protocol as well as for with Vmware blast protocol. Many of our user are affected by this crash and are waiting for a quick fix as soon as possible. A quick fix or workaround will help us greatly. Thanks!
Created attachment 279781 [details] Native snippet showing 526758, 543747 Updated native snippet that shows all crashes discovered so far.
Status update: 1) This is a Windows 10 bug. 2) It all begins when we use 'ImmAssociateContext' WINAPI. 3) A while ago I sent a bug report, but Microsoft ignored it. Upvoting it is a good idea: https://aka.ms/AA598rd 4) On 2019_09_04 I gave it to Sean Roark, who has Microsoft ticket open. Hopefully Microsoft will fix the bug and after Windows updates are installed it will be gone. 5) In the meanwhile, I tried to find workarounds to avoid triggering the bug. We already have two commits for it (see Bug 526758 and this bug). However, it seems that once API is touched, something will definitely break later. I already discovered around 6 different unique scenarios that crash. 6) I'm pretty much out of (reasonable) ideas. This Windows bug is a real beast. 7) Next week, I'm going to try to avoid touching the WINAPI at all. It seems that only a minority of programs ever use it for any real purpose. Eclipse itself doesn't seem to really use it, but initializes it in case it will be needed. Unfortunately, this will complicate code somewhat, which I'm not happy about, because things tend to stay even after the original reason is gone. Also, of course, programs that do need the API will still crash. 8) I didn't find any workarounds to help existing software without updating it.
What about adding a property to enable/disable IME allocation? That way if a developer explicitly requires them, they can choose to deal with the bug and everyone else can live without it. We just set OS.ImmAssociateContext (handle, 0); everywhere it occurs and it seems to have solved the problem in our case but that might not suit everyone.
Status update: -------------- I provided Microsoft with what they need, their team is analyzing it now, today they promised me to get back soon. In the meantime, I have evaluated the "lazy init" workaround I had in mind and I'm still not happy about it. The consequences of implementing it are a bit hard to predict. It seems that on some Win10 versions it could break IME input for Chinese/Japanese/etc completely. Therefore, I have decided to pause and see what Microsoft replies. It's quite likely that they will just fix the bug on their side, and everyone will be happy without the need for risky changes in Eclipse/SWT. Also, since the bug is mainly triggered by connecting RDP, I understand that it's an inconvenience, not something that really causes a lot of trouble. And the easiest workaround is to exit affected applications before connecting RDP. Regarding David's suggestion to introduce a system property: -------------- I don't think that this is a so good idea, because: 1) If disabled by default, then IME users might need to enable it, manually, on every computer. While to you the RDP crash is more important, to them being able to type text is definitely even more important. 2) If enabled by default, then again everyone who wants to avoid the crash will have to configure property on every computer.
Not sure it helps with the debugging st all but I have observed that the crash does not happen if I have started Eclipse from inside the RDP session. The crash only happens if I start Eclipse from a local session and then connect via RDP. If I start from RDP, I don’t see a crash regardless of whether subsequent connections are local or via RDP.
Scott, thanks for trying to help. I have already reduced the problem to a small snippet, so reproduction steps are no longer needed. The problem here is that the bug is not on Eclipse side, but in Windows, and it's so encompassing that none of my workarounds really worked - when avoiding one path leading to crash, I always ran into another.
(In reply to Alexandr Miloslavskiy from comment #88) > Status update: > 1) This is a Windows 10 bug. > 2) It all begins when we use 'ImmAssociateContext' WINAPI. > 3) A while ago I sent a bug report, but Microsoft ignored it. > Upvoting it is a good idea: https://aka.ms/AA598rd Yes, up-voting on the ticket should help push the priority higher. Hi Alexandr, Just checking if Microsoft team accepted the problem ? Not sure if they also assign an equivalent KB ID number to such issues.
On 2019-09-20 Microsoft said that "It could take weeks" for a team to look at this issue. I'm quite disappointed. Currently Sean (the one who initialed the Microsoft Support ticket) tries to push priority.
Hi Alexandr! We use IBM Notes and have the issue described here. We have already opened a ticket with Microsoft by ourselves (119091222001645) and need detailed information to proceed. Can you please share your ticket number and your Microsoft engineer so we can join our tickets? Maybe this will push priority. If some needs to know, our HCL ticket is CS0009141. Thanks Manfred
Got some news: This issue has got the Microsoft bug id 22449154. "The servicing team is actively working on this issue. The investigation is in process. There is no fix ETA. Once the issue will get fix they will release the fic publically."
(In reply to Manfred Mayr from comment #96) > Got some news: > > This issue has got the Microsoft bug id 22449154. > > "The servicing team is actively working on this issue. The investigation is > in process. There is no fix ETA. Once the issue will get fix they will > release the fic publically." Thank you for this info/update. Do you have a link handy for this Microsoft Bug ?
No, Microsoft didn't share more informations.
Sean's ticket number is 119070224004935. It seems that both of you got the same case manager now.
Information from Microsoft today: issue is still being analysed. Does anybody else have any details?
I can't confirm if it's fixed, but https://support.microsoft.com/en-us/help/4517211/windows-10-update-kb4517211 has the note: Addresses an issue with MSCTF.dll that causes an application to stop working.
Today I got the information from Microsoft that the cause of the issue was found and it has now to be repaired. There will be a official bug fix, but likely after October.
(In reply to Manfred Mayr from comment #102) > Today I got the information from Microsoft that the cause of the issue was > found and it has now to be repaired. > > There will be a official bug fix, but likely after October. Thanks for the update.
(In reply to Eclipse Genie from comment #41) > Gerrit change https://git.eclipse.org/r/144520 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=d4322185047c83ff4f7f4c994db4c89a401c73ca This caused severe regression in 4.13: crash on Windows while toggling "Find Toolbar" in the History view for Git shared projects. See bug 551067 comment 11. To reproduce: Revert commit d367093508dbaab34123d19f555ed5c94f289178 in Platform UI (it causes NPE on toggling), open History view, select any git shared project, toggle now "Ctrl+F" in History view till VM crashes (will usually crash on second toggle).
New Gerrit change created: https://git.eclipse.org/r/150661
Question: I see that this bug is marked as blocking for bug 548877 and assume that the crash there was also caused by the changes here - but neither here nor on bug 548877 I see explanation why they are linked and if my assumption is true. Is my assumption correct and crash on bug 548877 also caused by https://git.eclipse.org/r/#/c/145577? (In reply to Eclipse Genie from comment #105) > New Gerrit change created: https://git.eclipse.org/r/150661 This is a revert of the original commit (https://git.eclipse.org/r/#/c/145577) - with this revert, crash described in bug 551067 does not happen anymore. I would like to include this revert in 4.14 M1 (next week), because the crash affects more users as the original problem described here (all Windows users vs only those connected via RDP). If anyone has objections, please speak up, I plan to merge this revert tomorrow evening CET.
(In reply to David Robertson from comment #101) > I can't confirm if it's fixed, but > https://support.microsoft.com/en-us/help/4517211/windows-10-update-kb4517211 > has the note: > Addresses an issue with MSCTF.dll that causes an application to stop working. All 4 known crash types still happen after KB4517211. It seems that MSCTF.dll is plagued with bugs.
(In reply to Andrey Loskutov from comment #106) > Question: I see that this bug is marked as blocking for bug 548877 and > assume that the crash there was also caused by the changes here - but > neither here nor on bug 548877 I see explanation why they are linked and if > my assumption is true. I have identified that crash in Bug 550857 is the same. Later, Bug 548877 was derived from Bug 550857. Added comment in Bug 548877. > Is my assumption correct and crash on bug 548877 also > caused by https://git.eclipse.org/r/#/c/145577? You probably wanted to say https://git.eclipse.org/r/#/c/150661 ? I didn't expect that, but yes, it seems that it's caused by this patch. What we're dealing with is a Microsoft side bug and our desperate efforts to align moon and stars so it doesn't crash. But unfortunately MSCTF is bugged so badly that any our change only moves the crash elsewhere. > I would like to include this revert in 4.14 M1 (next week), because the > crash affects more users as the original problem described here (all Windows > users vs only those connected via RDP). Sounds reasonable. Currently I already know that fix in gerrit 150661 only fixes one RDP scenario and doesn't fix another which happens more often, so there's not much value in it. I have added new tests via gerrit https://git.eclipse.org/r/c/147074/ and the problem in Bug 551067 is Crash #4.
Gerrit change https://git.eclipse.org/r/147074 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=243c98a07bf2e6ea32d7bf94afd727ef2259babb
(In reply to Alexandr Miloslavskiy from comment #108) > (In reply to Andrey Loskutov from comment #106) > > Question: I see that this bug is marked as blocking for bug 548877 and > > assume that the crash there was also caused by the changes here - but > > neither here nor on bug 548877 I see explanation why they are linked and if > > my assumption is true. > > I have identified that crash in Bug 550857 is the same. Later, Bug 548877 > was derived from Bug 550857. Added comment in Bug 548877. > > > Is my assumption correct and crash on bug 548877 also > > caused by https://git.eclipse.org/r/#/c/145577? > > You probably wanted to say https://git.eclipse.org/r/#/c/150661 ? Sorry, I meant https://git.eclipse.org/r/144520 . > I didn't expect that, but yes, it seems that it's caused by this patch. What > we're dealing with is a Microsoft side bug and our desperate efforts to > align moon and stars so it doesn't crash. But unfortunately MSCTF is bugged > so badly that any our change only moves the crash elsewhere. > > > I would like to include this revert in 4.14 M1 (next week), because the > > crash affects more users as the original problem described here (all Windows > > users vs only those connected via RDP). > > Sounds reasonable. Currently I already know that fix in gerrit 150661 only > fixes one RDP scenario and doesn't fix another which happens more often, so > there's not much value in it. OK, I will also rebase & merge https://git.eclipse.org/r/#/c/150661 ASAP.
Gerrit change https://git.eclipse.org/r/150661 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3aa174cf25d0eed1b4a2c6f334a76cdc173c5699
(In reply to Eclipse Genie from comment #111) > Gerrit change https://git.eclipse.org/r/150661 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=3aa174cf25d0eed1b4a2c6f334a76cdc173c5699 For the record: with build I20191007-1800 and this patch merged we don't see crashes anymore on toggling EGit "Find" contribution in the History view.
(In reply to Andrey Loskutov from comment #112) > (In reply to Eclipse Genie from comment #111) > > Gerrit change https://git.eclipse.org/r/150661 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=3aa174cf25d0eed1b4a2c6f334a76cdc173c5699 > > For the record: with build I20191007-1800 and this patch merged we don't see > crashes anymore on toggling EGit "Find" contribution in the History view. Any chance to backport this into a 4.13 bugfix release?
(In reply to Michael Seele from comment #113) > Any chance to backport this into a 4.13 bugfix release? This can be backported easily, but there will be no official build anymore. So if you want to build SDK by yourself but based on "official" git state, cherry-pick the patch to R4_13_maintenance and push an extra commit to update SWT bundle manifest / pom version.
(In reply to Eclipse Genie from comment #41) > Gerrit change https://git.eclipse.org/r/144520 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=d4322185047c83ff4f7f4c994db4c89a401c73ca As per discussion in comment 47 to comment 53 the above fix patch was backported to 'R4_11_maintenance' and 'R4_6_maintenance' branches. Above patch had side-effect/crash seen in EGit and as per discussion from comment 106 to comment 112, we have reverted the original fix from master via comment 111. Hence I am planning to revert the backported fix from R4_11_maintenance' and 'R4_6_maintenance' branches as well.
New Gerrit change created: https://git.eclipse.org/r/150940
New Gerrit change created: https://git.eclipse.org/r/150941
Gerrit change https://git.eclipse.org/r/150940 was merged to [R4_11_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d294a00840fb80b870580e325266eeccf58545ad
Gerrit change https://git.eclipse.org/r/150941 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=642379f493c8ec2c18745b5a0d1030fbdb33c12f
So that other people can find it, here are native crash stacks, as obtained from https://bugs.eclipse.org/bugs/attachment.cgi?id=279781 Crash 1 (Fixed in Bug 526758) ----------------------------- msctf.dll!CCompositeContextAdapter::OnUnregistered msctf.dll!CInputContext::_Popped msctf.dll!CDocumentInputManager::_Pop msctf.dll!CDocumentInputManager::Pop msctf.dll!CBackingStore::Destroy msctf.dll!CBStoreHolderWin32::OnWindowDestroy msctf.dll!CicBridge::DropBackingStore msctf.dll!CicBridge::WinEventProc user32.dll!__ClientCallWinEventProc ntdll.dll!KiUserCallbackDispatcherContinue win32u.dll!NtUserDestroyWindow Crash 2 (Fixed in Bug 543747, later reverted because causes crash 4) ----------------------------- msctf.dll!CInputContext::_DoEditSession msctf.dll!CInputContext::_EditSessionQiCallback msctf.dll!CInputContext::OnLockGranted msctf.dll!CACPWrap::OnLockGranted msctf.dll!CBackingStore::RequestLock msctf.dll!CInputContext::_QueueItem msctf.dll!CInputContext::RequestEditSession msctf.dll!CCompositeContextAdapter::RequestEditSession msctf.dll!CInputContextAdapter::_ExecuteOperation msctf.dll!CInputContextAdapter::GetSelection TextInputFramework.dll!CTextInputClientOwnerAsync::GetSelectionAsync TextInputFramework.dll!TextInputClient::RegisterEditControl TextInputFramework.dll!TextInputClient::OnProxyCreated TextInputFramework.dll!CTextInputClientFreeThread::OnProxyCreated TextInputFramework.dll!MessageProxyReconnectAdapter::CreateRemoteProxy TextInputFramework.dll!MessageProxyReconnectAdapter::AttemptPullProxy TextInputFramework.dll!MessageProxyReconnectAdapter::s_AttemptPullProxy CoreMessaging.dll!Microsoft__CoreUI__Dispatch__TimeoutHandler$CallbackThunk CoreMessaging.dll!Microsoft::CoreUI::Dispatch::TimeoutManager::Callback_OnDispatch CoreMessaging.dll!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_DoWork CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_WindowProc user32.dll!UserCallWinProcCheckWow user32.dll!DispatchMessageWorker Crash 3 (was never fixed) ----------------------------- Same stack as crash 2 Crash 4 (was triggered by fix for crash 2, now reverted) ----------------------------- msctf.dll!CInputContext::_NotifyEndEdit msctf.dll!CInputContext::OnLockGranted msctf.dll!CACPWrap::OnLockGranted msctf.dll!CTextStoreImpl::RequestLock msctf.dll!CInputContext::OnLayoutChange msctf.dll!CIMEUIWindowHandler::ImeUIOnLayoutChange msctf.dll!CIMEUIWindowHandler::ImeUINotifyHandler msctf.dll!CIMEUIWindowHandler::ImeUIWndProcWorker user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!SendMessageToUI user32.dll!ImeNotifyHandler user32.dll!ImeWndProcWorker user32.dll!ImeWndProcW user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!RealDefWindowProcWorker user32.dll!DefWindowProcW user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!SendMessageW msctf.dll!UIComposition::UpdateCompositionRect msctf.dll!CIMEUIWindowHandler::ImeUINotifyHandler msctf.dll!CIMEUIWindowHandler::ImeUIWndProcWorker user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!SendMessageToUI user32.dll!ImeNotifyHandler user32.dll!ImeWndProcWorker user32.dll!ImeWndProcW user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!RealDefWindowProcWorker user32.dll!DefWindowProcW user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!SendMessageW imm32.dll!MakeIMENotify imm32.dll!ImmSetCompositionWindow user32.dll!ImeSetContextHandler user32.dll!ImeWndProcWorker user32.dll!ImeWndProcW user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!RealDefWindowProcWorker user32.dll!DefWindowProcW user32.dll!UserCallWinProcCheckWow user32.dll!SendMessageWorker user32.dll!SendMessageW imm32.dll!ImmSetActiveContext user32.dll!FocusSetIMCContext user32.dll!ImeSystemHandler user32.dll!ImeWndProcWorker user32.dll!ImeWndProcW user32.dll!UserCallWinProcCheckWow user32.dll!DispatchClientMessage user32.dll!__fnDWORD ntdll.dll!KiUserCallbackDispatcherContinue win32u.dll!NtUserDestroyWindow
(In reply to Manfred Mayr from comment #102) > Today I got the information from Microsoft that the cause of the issue was > found and it has now to be repaired. > > There will be a official bug fix, but likely after October. Is there any movement on the Microsoft side of things that we can tell?
Sean sent two queries about progress and got no replies.
Does this bug still affect bug 548877? (Is it a blocker?)
According to my understanding, Bug 548877 is no longer affected. As explained in Comment 120, fixing Crash 2 moved the problem into Crash 4, and Bug 548877 suffered from it. Now that the patch is reverted, Bug 548877 should be good.
(In reply to Alexandr Miloslavskiy from comment #124) > According to my understanding, Bug 548877 is no longer affected. > > As explained in Comment 120, fixing Crash 2 moved the problem into Crash 4, > and Bug 548877 suffered from it. Now that the patch is reverted, Bug 548877 > should be good. Ok, thank you for the confirmation.
(In reply to TW Bert from comment #121) > (In reply to Manfred Mayr from comment #102) > > Today I got the information from Microsoft that the cause of the issue was > > found and it has now to be repaired. > > > > There will be a official bug fix, but likely after October. > > Is there any movement on the Microsoft side of things that we can tell? Unfortunately no, the only information we get is that Microsoft is still working.
I am still having this issue. Whenever I have Eclipse GIT EE running and then I lock my PC, when i log in from home, it crashes. My co-workers are experiencing the same issue. Has there been a fix for this yet?
(In reply to Deana Cuffe from comment #127) > I am still having this issue. Whenever I have Eclipse GIT EE running and > then I lock my PC, when i log in from home, it crashes. My co-workers are > experiencing the same issue. Has there been a fix for this yet? It's a Windows issue and Microsoft is working on it, no information about time-line yet.
What is hard to understand is that if this bug is a Microsoft issue why it only shows with Eclipse. We use hundreds of Windows programs, among them IntelliJ Idea, and we found no problem with them when using Remote Desktop. Unfortunately it seems another annoying Eclipse issue that will get unresolved by years.
The short answer is that Eclipse's window library, SWT, uses ImmAssociateContext() WINAPI, which contains a bug. I was able to reproduce the bug in a short C++ snippet and I'm confident that it's a Microsoft bug. Also, Microsoft actually confirmed it, but is extremely lazy on fixing it. Now, why does SWT use this ImmAssociateContext() API? This is related to so called IME, which allows to input complex things like hieroglyphs. SWT provides an API to manipulate that, and to support this API, it does some extra things even if it's never used. I lack the knowledge to say whether this API is actually needed. Eclipse itself doesn't seem to use it.
Here's some timeline: Around 2019-09-11, Microsoft was eager to know the details of the crash, and I gave them everything necessary. Back then, I thought that it wouldn't take long to have it fixed. Around 2019-10-04, Microsoft confirmed that this is a bug on their side and it will be fixed. Of course, waiting 3 weeks (and two other guys pushing Microsoft to finally give a reply) didn't look too good, but I still had optimism for Microsoft fix to arrive soon enough. Back then, my team decided that it would be best to simply wait for the fix, because all other paths are significantly more complicated. At this point, It's hard to say what is best. I'm very disappointed about how Microsoft handles it.
>Now, why does SWT use this ImmAssociateContext() API? This is related to so called IME, which allows to input complex things like hieroglyphs. SWT provides an API to manipulate that, and to support this API, it does some extra things even if it's never used. I lack the knowledge to say whether this API is actually needed. Eclipse itself doesn't seem to use it. We have multiple SWT applications -- some RCP, some not -- that thankfully do NOT crash after connecting with Windows Remote Desktop. What's different with the Eclipse IDE?
The crash only occurs after disposing a Text control, there are different variations of crash depending on whether Text had input focus or not.
What would happen if you didn't dispose the text control?
>The crash only occurs after disposing a Text control, there >are different variations of crash depending on whether Text >had input focus or not. In the IDE, I'm seeing a crash immediately upon connection with Remote Desktop. In a custom RCP application, I'm not seeing a crash when disposing a Text control. (Details: showed the Text control, then remote-connected, then closed the dialog with the Text control.)
Proposal: Why don't you create an eclipse IDE build without IME Support? As far as i read all posts the IME is the major blocker with RDP. I can run a custom SWT application with text fields in RDP without any issue. We as a company are experiencing this issue now for over a year. Working and expecially presenting using remote desktop just is not possible that way. I also know that it is very hard to get MS to fix their own issues. However please think about your direct customers.
(In reply to Andrew Thomas from comment #135) > In a custom RCP application, I'm not seeing a crash when disposing a Text > control. (Details: showed the Text control, then remote-connected, then > closed the dialog with the Text control.) You need to dispose before connecting RDP.
Let's remove IME context propagation. As far as I can tell, it doesn't break StyledText IME integration. Shell.setImeInputMode will become global, instead of per-shell, but that method is broken anyway.
New Gerrit change created: https://git.eclipse.org/r/155174
Gerrit change https://git.eclipse.org/r/155174 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=4810cf67c305ecf4f1cc6885f365ce787b23f784
I've merged the fix in time for M1. Let's keep an eye for IME-related regressions.
(In reply to Nikita Nemkin from comment #141) > I've merged the fix in time for M1. Let's keep an eye for IME-related > regressions. Hi Nikita, Going through your patch comment: "Shell.setImeInputMode effect becomes global, instead of per-shell." Do you fore-see any issue with Shell.setImeInputMode() method API ?
(In reply to Niraj Modi from comment #142) > (In reply to Nikita Nemkin from comment #141) > > I've merged the fix in time for M1. Let's keep an eye for IME-related > > regressions. > > Hi Nikita, > Going through your patch comment: > "Shell.setImeInputMode effect becomes global, instead of per-shell." > Do you fore-see any issue with Shell.setImeInputMode() method API ? Aside from making setImeInputMode effect application-wide (or system-wide, depending on the settings)? No, I don't foresee any issues. setImeInputMode is broken, regardless of this patch, to the point that it should be deprecated and removed. It's win32-only, it uses obsolete native API, conversion mode is global on Win 10 by default, certain conversion modes don't work (i.e. I'm unable to switch to katakana when using Win 10 Japanese IME) Check out attached Shell_setImeInputMode_Test.java test program if you're interested.
(In reply to Alexandr Miloslavskiy from comment #137) > (In reply to Andrew Thomas from comment #135) > > In a custom RCP application, I'm not seeing a crash when disposing a Text > > control. (Details: showed the Text control, then remote-connected, then > > closed the dialog with the Text control.) > > You need to dispose before connecting RDP. I'm glad this issue is being fixed. As an observation, no crash occurred in a custom RCP application when disposing a Text control before connecting with Remote Desktop.
In Spain a lot of people don't give gifts at Christmas but at Epiphany or Three Kings' Day that is January 6. This fix is a good present for this day. Thanks a lot.
(In reply to Eclipse Genie from comment #140) > Gerrit change https://git.eclipse.org/r/155174 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=4810cf67c305ecf4f1cc6885f365ce787b23f784 Reopening for back-port to 4.11+, 4.8+ and 4.6.3+ branches will share a gerrit shortly.
New Gerrit change created: https://git.eclipse.org/r/156300
New Gerrit change created: https://git.eclipse.org/r/156303
New Gerrit change created: https://git.eclipse.org/r/156306
Gerrit change https://git.eclipse.org/r/156300 was merged to [R4_11_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a103d4913617daefa408f870c34aea9db6d40b37
Gerrit change https://git.eclipse.org/r/156303 was merged to [R4_8_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=fdc4a410b864e779b2405d585812b45e8d3994e6
Gerrit change https://git.eclipse.org/r/156306 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0ea9822e25ef9f8c506c194f3558738e4030d6ea
(In reply to Niraj Modi from comment #146) > (In reply to Eclipse Genie from comment #140) > > Gerrit change https://git.eclipse.org/r/155174 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=4810cf67c305ecf4f1cc6885f365ce787b23f784 > > Reopening for back-port to 4.11+, 4.8+ and 4.6.3+ branches will share a > gerrit shortly. Fix has been back-ported to R4_11_maintenance, R4_8_maintenance and R4_6_maintenance branches, closing now.
Excuse me, but how does one acquire the "R4_8_maintenance" build (or any of the other)? Is there a way to find it out? I saw it being added to 2020-03M1, but I cannot find the versions of the backports (and acquire one of them).
Finally, news from Microsoft: Windows patch is planned for Windows 1809, 1903, and 1909 in late April as long as no other issues arise from testing. The estimation is "3rd or 4th Tuesday of April". This should resolve the issue for all versions that doesn't contain recent Nikita's elimination of the code the triggered the bug.
Do you have any official ticket/case ID from MS?
Please see Comment 95 and Comment 99.
Is anyone get Windows 10 update fix
(In reply to Khoi Nguyen from comment #158) > Is anyone get Windows 10 update fix checked, seems only Win10 1809 is receiving fix? recent releases on 2020-04-21 KB4550945-1903 does not mention msctf.dll KB4550969-1809 mentions msctf.dll
I have tested with my native snippet. Windows 10 Version 1909 - all crashes still present Windows 10 version 2004 - all crashes fixed So it seems that 2004 contains the fix. As far as I understand, it will be released in end of this month.
It seems that Microsoft has postponed all non security patches. Therefore the fix for 1909 isn't available yet.
I can confirm that the Win10 2004 update solved our RDP problems with Eclipse (Version: Neon.2 Release (4.6.2) Build id: 20161208-0600). Sidenote: We're at such an old x32 version because of 3rd party commercial plugin dependencies (OpenEdge 11.6.3 x32). This shows the MS patch solves it, an Eclipse upgrade isn't strictly necessary. Very happy with this fix, cudos to the huge effort of Eclipse devs and MS devs alike.
(In reply to Alexandr Miloslavskiy from comment #160) > I have tested with my native snippet. > Windows 10 Version 1909 - all crashes still present > Windows 10 version 2004 - all crashes fixed > > So it seems that 2004 contains the fix. > As far as I understand, it will be released in end of this month. Thank you for the information. Unfortunately we cannot upgrade to Version 2004 in our organization because we're on the Entrprise LTSB/LTSC edition. Do you know which update will fix the issue, because then we could install it manually. Thanks in advance. Benjamin
Sorry, I don't know, and don't have LTSB to test. Note that since Nikita patch, Eclipse shouldn't be affected by the problem.
