http://bugs.winehq.org/show_bug.cgi?id=33384
--- Comment #19 from Anastasius Focht focht@gmx.net 2013-04-22 18:33:38 CDT --- Hello Dmitry,
thanks for the new patch v3.
--- quote --- Now the app goes even further. --- quote ---
Hmm... it still crashes here at the same place as my v2 patch in my previous comment (caused by different BitmapImpl layout).
--- quote --- ... 0028:CALL wpfgfx_v0300.MilComposition_SyncFlush(001b62f8) ret=0467945c 002b:trace:seh:raise_exception code=c0000005 flags=0 addr=0x5404056b ip=5404056b tid=002b 002b:trace:seh:raise_exception info[0]=00000000 002b:trace:seh:raise_exception info[1]=dea10004 002b:trace:seh:raise_exception eax=dea10000 ebx=00000000 ecx=0495f7f0 edx=54009440 esi=001d290c edi=048de5bc 002b:trace:seh:raise_exception ebp=048de590 esp=048de588 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 --- quote ---
So I added another IUnknown based interface, named "IMILUnknown2" at that offset. It crashed a bit further:
--- quote --- 0024:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a70e8) ret=0467945c 0027:trace:wincodecs:IMILUnknown2Impl_AddRef (0x1d2f6c) 0027:trace:wincodecs:BitmapImpl_AddRef (0x1d2f68) refcount=6 0027:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=0027 0027:trace:seh:raise_exception info[0]=00000000 0027:trace:seh:raise_exception info[1]=00000000 0027:trace:seh:raise_exception eax=001d2f6c ebx=00000000 ecx=7cbf6bd0 edx=048de57c esi=048de5d0 edi=048de5bc 0027:trace:seh:raise_exception ebp=048de580 esp=048de564 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 0027:trace:seh:call_stack_handlers calling handler at 0x7bc98301 code=c0000005 flags=0 ... Backtrace: =>0 0x00000000 (0x048de580) 1 0x540405fb in wpfgfx_v0300 (+0x405fa) (0x048de58c) 2 0x540405c7 in wpfgfx_v0300 (+0x405c6) (0x048de5a4) 3 0x54040140 in wpfgfx_v0300 (+0x4013f) (0x048de604) --- quote ---
Caller code:
--- snip --- 5403039B MOV ECX,DWORD PTR DS:[EAX] ; windowscodecs.IMILUnknown2Impl_Vtbl ... 5403039E LEA EDX,[EBP-8] 540303A1 PUSH EDX 540303A2 LEA EDX,[EBP-4] 540303A5 PUSH EDX 540303A6 PUSH EAX 540303A7 CALL DWORD PTR DS:[ECX+0C] ; ?? 540303AA MOV EDI,EAX 540303AC TEST EDI,EDI 540303AE JL 5408C08B 540303B4 FLDZ --- snip ---
That new unknown method at offset 0x0C has 2 parameters which are of "out" semantics again (the caller expects values written to supplied stack addresses). What if one of the already known interfaces/vtables are actually expected at that offset BitmapImpl+0x0C (it's just a member order/layout issue)?
IWICBitmap and IMILBitmapSource have similar interfaces, except for 0x20+ offsets.
--- snip --- +0x00: QueryInterface +0x04: AddRef +0x08: Release +0x0C: GetSize +0x10: GetPixelFormat +0x14: GetResolution +0x18: CopyPalette/GetPalette +0x1C: CopyPixels --- snip ---
IWICBitmap::GetSize() which lives at method offset 0x0C matches the signature of the caller. I moved the "dummy1" member in between to have IWICBitmap located at BitmapImpl+0x0C
--- snip --- typedef struct BitmapImpl { IMILBitmapSource IMILBitmapSource_iface; // +0x00 IMILUnknown1 IMILUnknown1_iface; // +0x04 void *dummy1; // +0x08 IWICBitmap IWICBitmap_iface; // +0x0C void *dummy2; void *dummy3; --- snip ---
This crashes again with following trace:
--- snip --- 0028:CALL wpfgfx_v0300.MilComposition_SyncFlush(001ae5f8) ret=0467945c 002b:trace:wincodecs:BitmapImpl_AddRef (0x1d3024) refcount=6 002b:trace:wincodecs:BitmapImpl_GetSize (0x1d3024,0x48de57c,0x48de578) 002b:trace:wincodecs:BitmapImpl_QueryInterface (0x1d3024,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de2e8) 002b:trace:wincodecs:BitmapImpl_Release (0x1d3024) refcount=5 002b:fixme:d3d9:Direct3DShaderValidatorCreate9 stub 002b:err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glMapBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1028 002b:err:d3d:wined3d_buffer_unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glFlushMappedBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1140 002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub 002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub 002b:fixme:d3d:resource_check_usage Unhandled usage flags 0x8. 002b:trace:wincodecs:BitmapImpl_AddRef (0x1d3024) refcount=6 002b:trace:wincodecs:BitmapImpl_GetSize (0x1d3024,0x48de40c,0x48de408) 002b:trace:wincodecs:BitmapImpl_QueryInterface (0x1d3024,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de178) 002b:trace:wincodecs:BitmapImpl_Lock (0x1d3024,0x48ddad0,48ddbd8,0x4968498) 002b:trace:wincodecs:BitmapImpl_QueryInterface (0x1d3024,{181fa62c-0133-43d4-8d5c-639c3487783f},0x48dd994) 002b:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=002b 002b:trace:seh:raise_exception info[0]=00000000 002b:trace:seh:raise_exception info[1]=00000000 002b:trace:seh:raise_exception eax=00000000 ebx=540395a9 ecx=00000000 edx=54024bb8 esi=048ddadc edi=048ddae8 002b:trace:seh:raise_exception ebp=0494a468 esp=048dd9a0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010282 --- snip ---
Tidbit: these GL_INVALID_xxx messages seem to have been surfaced with recent Wine commits (last days), I've not seen them before in that context. Maybe this is related bug 33426 ?
Anyway, that looked better but I got stuck again - something was still wrong. All members except for offset 0x04 were accessed in vtable manner. So I moved the "dummy1" to offset 0x04 and settled with the following layout (could be still very wrong but it produced best results):
--- snip --- typedef struct BitmapImpl { IMILUnknown1 IMILUnknown1_iface; // +0x00 void *dummy1; // +0x04 IMILBitmapSource IMILBitmapSource_iface; // +0x08 IWICBitmap IWICBitmap_iface; // +0x0C void *dummy2; void *dummy3; ... --- snip ---
I now hit the "deadxxxx" method stub from your patch.
--- snip --- 0024:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a7f10) ret=0467945c 0027:trace:wincodecs:BitmapImpl_AddRef (0x1d2fac) refcount=6 0027:trace:wincodecs:BitmapImpl_GetSize (0x1d2fac,0x48de57c,0x48de578) 0027:trace:wincodecs:IMILBitmapImpl_QueryInterface (0x1d2fa8,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de2e8) 0027:trace:wincodecs:BitmapImpl_Release (0x1d2fac) refcount=5 0027:fixme:d3d9:Direct3DShaderValidatorCreate9 stub 0027:err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glMapBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1028 0027:err:d3d:wined3d_buffer_unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glFlushMappedBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1140 0027:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub 0027:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub 0027:fixme:d3d:resource_check_usage Unhandled usage flags 0x8. 0027:trace:wincodecs:BitmapImpl_AddRef (0x1d2fac) refcount=6 0027:trace:wincodecs:BitmapImpl_GetSize (0x1d2fac,0x48de40c,0x48de408) 0027:trace:wincodecs:IMILBitmapImpl_QueryInterface (0x1d2fa8,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de178) 0027:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1d2fa8,0x48ddad0) 0027:err:wincodecs:dead0004 0x1d2fb0 0027:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4966ce0 ip=04966ce0 tid=0027 0027:trace:seh:raise_exception info[0]=00000000 0027:trace:seh:raise_exception info[1]=bd5a005c 0027:trace:seh:raise_exception eax=dead0004 ebx=048dd990 ecx=001d2fb0 edx=048def48 esi=00000001 edi=048ddae8 0027:trace:seh:raise_exception ebp=048ddbd8 esp=048dd990 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 --- snip ---
There is still a strange QueryInterface with "{0ccd7824-dc16-4d09-bca8-6b09c4ef5535}" in between (IID not documented?).
The caller code, leading to crash:
--- snip --- 54039229 MOV DWORD PTR SS:[EBP+8],ESI 5403922C MOV EDX,DWORD PTR DS:[ECX] ; OFFSET windowscodecs.dea20000 5403922E LEA ESI,[EBP+8] 54039231 PUSH ESI 54039232 PUSH EAX 54039233 PUSH ECX 54039234 CALL DWORD PTR DS:[EDX+0C] ; windowscodecs.dead0004 --- snip ---
Stack values:
--- snip --- 0495D974 002069E8 ; This 002069E8 -> 7CB83674 ; windowscodecs.dea20000 0495D978 00000001 ; arg1 ? 0495D97C 0495D990 ; arg2 -> stack "out" parameter? ... 0495D990 00000000 --- snip ---
Looks like another IUnknown based interface at BitmapImpl+0x10 + a stub method, taking 2 params?
Your "stub" dea20000 interface pretty much matches the first 3 method signatures of IUnknown:
--- snip --- static HRESULT WINAPI dead0001(void *iface, REFIID iid, void **ppv) { ERR("(%p,%s,%p)\n", iface, debugstr_guid(iid), ppv); *ppv = (void *)0xdead1234; return S_OK; } static HRESULT WINAPI dead0002(void *arg1) { ERR("(%p)\n", arg1); return 0xdead0002; } static HRESULT WINAPI dead0003(void *arg1) { ERR("(%p)\n", arg1); return 0xdead0003; } --- snip ---
Changing your "dead0004" stub to:
--- snip --- static HRESULT WINAPI dead0004(void *iface, void *arg1, void *arg2) { ERR("(%p,%p,%p)\n", iface, arg1, arg2); return 0xdead0004; } --- snip ---
yields better results:
--- snip --- 003a:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a7f10) ret=0467945c 003d:trace:wincodecs:BitmapImpl_AddRef (0x1ce3c4) refcount=6 003d:trace:wincodecs:BitmapImpl_GetSize (0x1ce3c4,0x48de57c,0x48de578) 003d:trace:wincodecs:IMILBitmapImpl_QueryInterface (0x1ce3c0,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de2e8) 003d:trace:wincodecs:BitmapImpl_Release (0x1ce3c4) refcount=5 003d:fixme:d3d9:Direct3DShaderValidatorCreate9 stub 003d:err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glMapBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1028 003d:err:d3d:wined3d_buffer_unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glFlushMappedBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1140 003d:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub 003d:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub 003d:fixme:d3d:resource_check_usage Unhandled usage flags 0x8. 003d:trace:wincodecs:BitmapImpl_AddRef (0x1ce3c4) refcount=6 003d:trace:wincodecs:BitmapImpl_GetSize (0x1ce3c4,0x48de40c,0x48de408) 003d:trace:wincodecs:IMILBitmapImpl_QueryInterface (0x1ce3c0,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de178) 003d:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce3c0,0x48ddad0) 003d:err:wincodecs:dead0004 (0x1ce3c8,0x1,0x48dd990) 003d:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce3c0,0x48dd96c) 003d:err:wincodecs:dead0004 (0x1ce3c8,0x1,0x48dd8e8) 003d:trace:wincodecs:IMILBitmapImpl_GetPixelFormat (0x1ce3c0,0x48dd8b8) 003d:trace:wincodecs:BitmapImpl_GetSize (0x1ce3c4,0x48dd940,0x48dd944) 003d:err:wincodecs:dead0004 (0x1ce3c8,0x1,0x48dd8b4) 003d:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=003d 003d:trace:seh:raise_exception info[0]=00000000 003d:trace:seh:raise_exception info[1]=00000000 003d:trace:seh:raise_exception eax=7cb7a7c4 ebx=04962cc8 ecx=001ce3b8 edx=00000000 esi=04962d70 edi=048dd900 003d:trace:seh:raise_exception ebp=048dd8c4 esp=048dd8b4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 --- snip ---
That's progress ... but I'm not sure if we're on the right track here and how much work is still left until we see the picture.
Regards