http://bugs.winehq.org/show_bug.cgi?id=35361
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47259|0 |1 is obsolete| |
--- Comment #20 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 47533 --> http://bugs.winehq.org/attachment.cgi?id=47533 Patch
I spent some more time on this. I can't really claim I understand IME or how all this should work but it seems to me that something weird is happening. Let me try to explain with some excerpts from a +relay,+imm,+tid log.
First, one thread wants to get the IMM context of the game window:
0074:Call imm32.ImmGetContext(0005017c) ret=3f25092a 0074:trace:imm:ImmGetContext 0x5017c 0074:Call user32.IsWindow(0005017c) ret=7dce48f6 0074:Ret user32.IsWindow() retval=00000001 ret=7dce48f6 0074:Call user32.GetPropW(0005017c,7dce6680 L"WineImmHIMCProperty") ret=7dce485b 0074:Ret user32.GetPropW() retval=00000000 ret=7dce485b ...
There is no current context at this point, so a new one is generated:
... 0074:trace:imm:ImmCreateContext Created context 0x1baa80 0074:trace:imm:ImmGetContext returning 0x1baa80 0074:Ret imm32.ImmGetContext() retval=001baa80 ret=3f25092a 0074:Call imm32.ImmAssociateContext(0005017c,00149fa8) ret=3f25093f
Notice how that thread associates a completely different pointer as an IMM context compared to the pointer just received. Peeking with winedbg it looks like that points to one byte set to 0 followed by some string apparently from the process environment. Anyway, when later on another thread receives a keypress, it ends up calling ImmProcessKey:
005b:Call imm32.ImmProcessKey(0005017c,04090409,00000020,40390001,00000000) ret=7e9ad7ac 005b:trace:imm:ImmGetContext 0x5017c 005b:Call user32.IsWindow(0005017c) ret=7d2528f6 005b:Ret user32.IsWindow() retval=00000001 ret=7d2528f6 005b:Call user32.GetPropW(0005017c,7d254680 L"WineImmHIMCProperty") ret=7d25285b 005b:Ret user32.GetPropW() retval=00149fa8 ret=7d25285b 005b:warn:imm:ImmGetContext Wrong magic.
That's with the patch I'm now attaching, otherwise you get a crash here.
Regarding the patch, I've no idea if doing such a check makes sense or if that is the right place for it. Maybe ImmProcessKey shouldn't be called at all in this case. Another possibility is that there is some other Wine bug that causes that weird pointer to be passed to ImmAssociateContext, but I don't see anything in the log suggesting that and I'm not sure I want to step into gameoverlayrenderer.dll code to verify.