Hello Nikolay,
On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov bunglehead@gmail.com wrote:
This could be some a different bug, and putting exception handler around it is not necessary a right solution.
Good catch, I think you are right.
I found ImmLockIMC()/ImmUnLockIMC()/etc are called even after ImmDestroyContext(), the latter frees the input method context if the call successes, but the former try to access the IMC.
I have a test case show that in some case native ImmDestroyContext() fails but builtin ImmDestroyContext() success: https://testbot.winehq.org/JobDetails.pl?Key=26499&log_206=1#k206
That is why Office die on Wine but live on Windows, ImmDestroyContext() fails so following ImmLockIMC()/ImmUnLockIMC()/ImmGetIMCCSize() are safe, but on Wine ImmDestroyContext() success and free the memory of the IMC, and... Boom!
--- snip --- Call imm32.ImmDestroyContext(08a29b28) ret=3927e447 Ret imm32.ImmDestroyContext() retval=00000001 ret=3927e447 /* success, free the IMC (hIMC == 0x08a29b28) */ Call imm32.ImmLockIMC(08a29b28) ret=09ea2c54 /* would die sooner or later ... */ Ret imm32.ImmLockIMC() retval=08a29b2c ret=09ea2c54 ... Call imm32.ImmGetIMCCSize(00000008) ret=09ea3545 /* 0x00000008 comes from hIMC->IMC.hPrivate, unfortunately hIMC is freed... */ --- snip ---
I need more tests to figure out what is the necessary and sufficient conditions to make ImmDestroyContext fails.
Thanks for the help!