http://bugs.winehq.org/show_bug.cgi?id=33384
--- Comment #16 from Anastasius Focht focht@gmx.net 2013-04-19 06:03:51 CDT --- Hello folks,
a bit more info...
The caller code of current crash (with v2 patch):
--- snip --- Wine-dbg>disas 0x54040560 0x54040560: pushl %esi 0x54040561: movl 0x2c(%ecx),%esi 0x54040564: testl %esi,%esi 0x54040566: jz 0x5404056e 0x54040568: movl 0x0(%esi),%eax 0x5404056a: pushl %esi 0x5404056b: call *0x4(%eax) 0x5404056e: movl 0x8(%ebp),%eax 0x54040571: movl %esi,0x0(%eax) 0x54040573: xorl %eax,%eax
Wine-dbg>info reg Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:5404056b ESP:0495e588 EBP:0495e590 EFLAGS:00010202( R- -- I - - - ) EAX:00000005 EBX:00000000 ECX:04a08048 EDX:54009440 ESI:00200c4c EDI:0495e5bc --- snip ---
Looks like interface/vtable method calling code again. "eax" has a strange value which is read from "[esi]".
Dumping the memory around "esi" shows an interesting thing:
--- snip --- Wine-dbg>x/10x $esi-20 0x00200c38: 00000068 00455355 7cbf61c0 7cbf61e4 0x00200c48: 7cbf6180 00000005 00000000 00000000 0x00200c58: 00000000 049a8038 --- snip ---
"00455355" looks familar? Yes, heap magic. Resolving all other values shows this is indeed our BitmapImpl.
--- snip --- 00200c38 00000068 ; block size 00200c3c 00455355 ; "USE" heap magic 00200c40 7cc2b1c0 ; windowscodecs.IMILBitmapImpl_Vtbl 00200c44 7cc2b1e4 ; windowscodecs.IMILUnknown1Impl_Vtbl 00200c48 7cc2b180 ; windowscodecs.BitmapImpl_Vtbl 00200c4c 00000005 ; ref (refcount) 00200c50 00000000 --- snip ---
It seems the WPF code has knowledge of the underlying WIC/MIL bitmap object implementation and tries to directly access the member(s). Because Wine's BitmapImpl has a different layout, the "refcount" is mistaken as interface/vtable pointer.
Regards