[Bug 33384] New: Basic WPF application fails to handle images
http://bugs.winehq.org/show_bug.cgi?id=33384 Bug #: 33384 Summary: Basic WPF application fails to handle images Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: leonidbrook(a)gmail.com Classification: Unclassified I created a simple application that display an image loaded from a file (see MainWindow.xaml). The file added as a "Resource" to the application project. Basically, the only thing I added to the base skeleton, is <Image Source="beta.png"/>. The application fails at System.Media.Imaging.BitmapSource.get_DUCECompatibleMILPtr() with System.InvalidCastException: Specified case is not valid. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet CC| |focht(a)gmx.net Severity|major |normal --- Comment #1 from Anastasius Focht <focht(a)gmx.net> 2013-04-14 10:59:38 CDT --- Hello, which WPF version does your application target (WPF 4.0 or WPF 3.5 SPx)? Make sure you have all required .NET Frameworks and Service Packs installed in the WINEPREFIX your application is run from (following appdb/winetricks recipes). Please attach the application binary and all needed resources (preferable a simple version). Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #2 from leon <leonidbrook(a)gmail.com> 2013-04-14 12:59:14 CDT --- Created attachment 44184 --> http://bugs.winehq.org/attachment.cgi?id=44184 WPF executable, should show a single picture -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #3 from leon <leonidbrook(a)gmail.com> 2013-04-14 13:02:03 CDT --- Created attachment 44185 --> http://bugs.winehq.org/attachment.cgi?id=44185 WPF application sources The picture file added to the Visual Studio based project and defined as a resource. After that used in MainWindow.xaml. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #4 from leon <leonidbrook(a)gmail.com> 2013-04-14 13:04:43 CDT --- Hello, The application was developed with Visual Studio 2010, targeting .NET 3.5. I think all required prerequisites were installed. Is there any difference between handling .NET 3.5 and 4.0 by Wine? Is there chance that the same application works when targeting .NET 4.0? Thanks a lot, Leon. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |windowscodecs Summary|Basic WPF application fails |Basic WPF applications |to handle images |using .NET 3.5 WPF fails to | |handle images | |(windowscodecs | |{7543696a-bc8d-46b0-5f81-8d | |95728972be} = | |IMILBitmapSource | |unsupported) Ever Confirmed|0 |1 --- Comment #5 from Anastasius Focht <focht(a)gmx.net> 2013-04-14 14:23:12 CDT --- Hello, confirming. It seems that .NET Framework WPF 3.x queries an internal interface that Wine builtin windowscodecs doesn't support. --- snip --- $ WINEDEBUG=+tid,+seh,+loaddll,+process,+msvcrt,+snoop,+wincodecs wine ./WineTest.exe ... 002b:CALL wpfgfx_v0300.MilResource_SendCommand(0032dd70,00000018,0019a108) ret=046790e0 002b:RET wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0 002b:CALL wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock() ret=042f08c3 002b:RET wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock() retval=00000000 ret=042f08c3 002b:CALL wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel(0019a108,00000031,0032dd3c) ret=042f0a20 002b:RET wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel() retval=00000000 ret=042f0a20 002b:CALL wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock() ret=042f08c3 002b:RET wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock() retval=00000000 ret=042f08c3 002b:CALL wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel(0019a108,00000062,0032dcf8) ret=042f0a20 002b:RET wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel() retval=00000000 ret=042f0a20 002b:trace:wincodecs:BitmapImpl_CopyPixels (0x1b6d30,0x32dc44,4,4,0x84ce6c) 002b:CALL wpfgfx_v0300.MILQueryInterface(001b6d30,0032dc34,0032dc9c) ret=042f123d 002b:trace:wincodecs:BitmapImpl_QueryInterface (0x1b6d30,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c) 002b:RET wpfgfx_v0300.MILQueryInterface() retval=80004002 ret=042f123d ... 002b:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b83aabb ip=7b83aabb tid=002b 002b:trace:seh:raise_exception info[0]=80004002 002b:trace:seh:raise_exception eax=7b826891 ebx=7b8b96b0 ecx=80004002 edx=0032da94 esi=0032db18 edi=00132d10 002b:trace:seh:raise_exception ebp=0032dad8 esp=0032da74 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000283 002b:trace:seh:call_stack_handlers calling handler at 0x79f908a2 code=e0434f4d flags=1 002b:trace:seh:_except_handler4_common exception e0434f4d flags=1 at 0x7b83aabb handler=0x79f908a2 0x32d710 0x32d5dc cookie=a6e038fa scope table=0x79eda938 cookies=-2/0,-72/0 002b:trace:seh:_except_handler4_common level 0 prev -2 filter 0x79eda969 002b:trace:seh:_except_handler4_common filter returned CONTINUE_SEARCH 002b:trace:seh:_except_handler4_common reached -2, returning ExceptionContinueSearch 002b:trace:seh:call_stack_handlers handler at 0x79f908a2 returned 1 002b:trace:seh:call_stack_handlers calling handler at 0x79fb4869 code=e0434f4d flags=1 ... --- snip --- Managed backtrace: --- snip --- System.InvalidCastException: Specified cast is not valid. at System.Windows.Media.Imaging.BitmapSource.get_DUCECompatibleMILPtr() at System.Windows.Media.Imaging.BitmapSource.UpdateBitmapSourceResource(Channel channel, Boolean skipOnChannelCheck) at System.Windows.Media.Imaging.BitmapSource.UpdateResource(Channel channel, Boolean skipOnChannelCheck) at System.Windows.Media.Imaging.BitmapSource.AddRefOnChannelCore(Channel channel) at System.Windows.Media.Imaging.BitmapSource.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel) at System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel) at System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean isOnChannel) at System.Windows.Media.Visual.UpdateContent(RenderContext ctx, VisualProxyFlags flags, Boolean isOnChannel) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle) ... at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.Render(RenderContext ctx, UInt32 childIndex) at System.Windows.Media.CompositionTarget.Compile(Channel channel) at System.Windows.Media.CompositionTarget.System.Windows.Media.ICompositionTarget.Render(Boolean inResize, Channel channel) at System.Windows.Media.MediaContext.Render(ICompositionTarget resizedCompositionTarget) at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget) at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget) at System.Windows.Media.MediaContext.Resize(ICompositionTarget resizedCompositionTarget) at System.Windows.Interop.HwndTarget.OnResize() --- snip --- Google suggests that "7543696A-BC8D-46b0-5F81-8D95728972BE" is "IMILBitmapSource". It's also mentioned in United States Patent 7511718 "Media integration layer": http://www.freepatentsonline.com/7511718.html The interface has the same members/signatures as IWICBitmapSource except for CopyPalette() -> GetPalette(). You can work around installing native 'windowscodecs' using 'winetricks windowscodecs' recipe. Be aware the installer seems very unstable = needs several tries, most likely regressed over long time. With native windowscodecs override your application properly loads and displays the picture on my system. --- quote --- Is there any difference between handling .NET 3.5 and 4.0 by Wine? Is there chance that the same application works when targeting .NET 4.0? --- quote --- Not by Wine (as long it's not an underlying win32 API insufficiency) but there are of course major WPF versions (3.0, 3.5, 3.5sp1, 4.0, 4.5) that have whole rendering engines underneath rewritten, interfaces obsoleted/added and the like. This is outside of Wine's scope, I suggest to read on MSDN. Regarding .NET Framework 4.0 (containing WPF 4.0) ... you can try by rebuilding/deploying your app. Be sure to set the application target framework to ".NET Framework 4 Client Profile" in build settings. For testing I suggest a separate WINEPREFIX, created with 'winetricks -q dotnet40'. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com --- Comment #6 from Vincent Povirk <madewokherd(a)gmail.com> 2013-04-14 16:23:38 CDT --- Argh. What's the signature on GetPalette? Are you getting this information from the WPF .NET metadata (seems like the most obvious way to do it, but it's also code I can't personally look at)? Did you verify the method order? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #7 from Anastasius Focht <focht(a)gmx.net> 2013-04-14 17:11:06 CDT --- Hello Vincent, the method signatures and order are exactly the same so I'm wondering why this second interface exist (solely for performance reasons?). The definition for Wine's "wincodec.idl" would be as follows (I replaced the GUID and CopyPalette method name): --- snip --- [ object, uuid(7543696a-bc8d-46b0-5f81-8d95728972be) ] interface IMILBitmapSource : IUnknown { HRESULT GetSize( [out] UINT *puiWidth, [out] UINT *puiHeight); HRESULT GetPixelFormat( [out] WICPixelFormatGUID *pPixelFormat); HRESULT GetResolution( [out] double *pDpiX, [out] double *pDpiY); HRESULT GetPalette( [in] IWICPalette *pIPalette); HRESULT CopyPixels( [in] const WICRect *prc, [in] UINT cbStride, [in] UINT cbBufferSize, [out, size_is(cbBufferSize)] BYTE *pbBuffer); } --- snip --- So technically if the vtable layout and method signatures are exactly the same, we could get away by just using our BitmapImpl? Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #8 from Anastasius Focht <focht(a)gmx.net> 2013-04-14 18:13:26 CDT --- Hello folks, well it seems I was wrong on "exact" the same parameters. It seems there is at least another deviation in the interface. For testing I added IMILBitmapSource to .idl file and allowed BitmapImpl_QueryInterface to return BitmapImpl for IID_IMILBitmapSource. This gets the app a little farther only to run into: --- snip --- ... 002b:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check return>) ret=044123d7 002b:trace:wincodecs:BitmapImpl_GetPixelFormat (0x1b2de8,0x32dbc4) 002b:trace:wincodecs:BitmapImpl_AddRef (0x1b2de8) refcount=5 002b:trace:wincodecs:BitmapImpl_GetSize (0x1b2de8,0x32dbb4,0x32dbb0) 002b:trace:wincodecs:BitmapImpl_GetResolution (0x1b2de8,0x32dc40,0x32dc38) 002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub 002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub 002b:trace:wincodecs:BitmapImpl_Release (0x1b2de8) refcount=4 002b:RET wpfgfx_v0300.MilResource_SendCommandBitmapSource(00000010,001b2de8,00000001,00000001,0018b1d0) retval=80070216 ret=044123d7 ... 002b:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b83aabb ip=7b83aabb tid=002b 002b:trace:seh:raise_exception info[0]=80131516 002b:trace:seh:raise_exception eax=7b826891 ebx=7b8b96b0 ecx=80131516 edx=0032db38 esi=0032dbc0 edi=00133148 002b:trace:seh:raise_exception ebp=0032db78 esp=0032db14 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000283 002b:trace:seh:call_stack_handlers calling handler at 0x79f908a2 code=e0434f4d flags=1 ... 0033:err:eventlog:ReportEventW L"clr20r3" 0033:err:eventlog:ReportEventW L"winetest.exe" 0033:err:eventlog:ReportEventW L"1.0.0.0" 0033:err:eventlog:ReportEventW L"5168fd72" 0033:err:eventlog:ReportEventW L"presentationcore" 0033:err:eventlog:ReportEventW L"3.0.0.0" 0033:err:eventlog:ReportEventW L"488f140b" 0033:err:eventlog:ReportEventW L"480" 0033:err:eventlog:ReportEventW L"29" 0033:err:eventlog:ReportEventW L"system.overflowexception" 0033:err:eventlog:ReportEventW L"NIL" --- snip --- Managed backtrace: --- snip --- System.OverflowException: The image data generated an overflow during processing. ---> System.ArithmeticException: Overflow or underflow in the arithmetic operation. --- End of inner exception stack trace --- at System.Windows.Media.Composition.DUCE.Channel.SendCommandBitmapSource(ResourceHandle imageHandle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap, Boolean systemMemoryBitmap) at System.Windows.Media.Imaging.BitmapSource.UpdateBitmapSourceResource(Channel channel, Boolean skipOnChannelCheck) at System.Windows.Media.Imaging.BitmapSource.UpdateResource(Channel channel, Boolean skipOnChannelCheck) at System.Windows.Media.Imaging.BitmapSource.AddRefOnChannelCore(Channel channel) at System.Windows.Media.Imaging.BitmapSource.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel) at System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel) at System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean isOnChannel) at System.Windows.Media.Visual.UpdateContent(RenderContext ctx, VisualProxyFlags flags, Boolean isOnChannel) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) at System.Windows.Media.Visual.Render(RenderContext ctx, UInt32 childIndex) at System.Windows.Media.CompositionTarget.Compile(Channel channel) at System.Windows.Media.CompositionTarget.System.Windows.Media.ICompositionTarget.Render(Boolean inResize, Channel channel) at System.Windows.Media.MediaContext.Render(ICompositionTarget resizedCompositionTarget) at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget) at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget) at System.Windows.Media.MediaContext.Resize(ICompositionTarget resizedCompositionTarget) at System.Windows.Interop.HwndTarget.OnResize() --- snip --- After a bit of debugging it seems the pixel format is not correct. The overflow happens when .NET MIL looks at BitmapImpl_GetPixelFormat() data. It seems IMILBitmapSource::GetPixelFormat is expected as integer value (enum?), not a GUID. The code verifies the parameter value range to 0..0x2c and throws the overflow error > 0x2c. I don't have the WIC SDK but maybe there exist an enumerator for pixel formats (which maps to GUIDs and vise versa). So we need a separate impl to cope with different GetPixelFormat() at least. Still BitmapImpl code could be reused. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #9 from Vincent Povirk <madewokherd(a)gmail.com> 2013-04-14 18:33:38 CDT --- There isn't any such enum, but most of the pixel formats that were there originally differ only by the last byte, which happens to be within the needed range: http://source.winehq.org/source/include/wincodec.idl#L177 Or if not, it shouldn't be hard to write tests to find the values. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #10 from Anastasius Focht <focht(a)gmx.net> 2013-04-15 16:45:08 CDT --- Hello Vincent, --- quote --- There isn't any such enum, but most of the pixel formats that were there originally differ only by the last byte, which happens to be within the needed range: http://source.winehq.org/source/include/wincodec.idl#L177 --- quote --- the last byte of the format GUID seems indeed to map to enum int value. --- snip --- Indexed1 = 1, Indexed2 = 2, Indexed4 = 3, Indexed8 = 4, BlackWhite = 5, Gray2 = 6, Gray4 = 7, Gray8 = 8, ... --- snip --- To avoid duplicating BitmapImpl/iface code I quickly hacked BitmapImpl_QueryInterface() to set a hint in BitmapImpl struct when IID_IMILBitmapSource is requested. With that hint I was able to distinguish the out parameter type for BitmapImpl_GetPixelFormat() -> WICPixelFormatGUID* vs. int* (enum). I used a GUID to enum translator similar to what converter.c/FormatConverter does (pixelformat). That worked but the whole thing crashed later... There is a vtable access/call after CopyPixels method offset which happens to be "BitmapImpl_Lock" in Wine (4 params). Unfortunately the stack got imbalanced by 8 bytes after the method call (only 2 params get pushed). This hints at a different BitmapImpl vtable layout for MIL. +0x00: QueryInterface +0x04: AddRef +0x08: Release +0x0C: GetSize +0x10: GetPixelFormat +0x14: GetResolution +0x18: CopyPalette/GetPalette +0x1C: CopyPixels +0x20: ??? --- snip --- ... 0024:CALL wpfgfx_v0300.MILQueryInterface(001babb0,0032dc34,0032dc9c) ret=042f123d 0024:trace:wincodecs:BitmapImpl_QueryInterface (0x1babb0,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1babb0) refcount=4 0024:RET wpfgfx_v0300.MILQueryInterface() retval=00000000 ret=042f123d 0024:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check return>) ret=042f23d7 0024:trace:wincodecs:BitmapImpl_GetPixelFormat (0x1babb0,0x32dbc4) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1babb0) refcount=5 0024:trace:wincodecs:BitmapImpl_GetSize (0x1babb0,0x32dbb4,0x32dbb0) 0024:trace:wincodecs:BitmapImpl_GetResolution (0x1babb0,0x32dc40,0x32dc38) 0024:trace:wincodecs:BitmapImpl_Lock (0x1babb0,0x32db90,32dc38,0x180) 0024:trace:wincodecs:BitmapImpl_GetSize (0x1babb0,0x49907a8,0x49907ac) 0024:trace:wincodecs:BitmapImpl_GetPixelFormat (0x1babb0,0x49907b8) 0024:trace:wincodecs:BitmapImpl_GetResolution (0x1babb0,0x32db54,0x32db4c) 0024:trace:wincodecs:BitmapImpl_QueryInterface (0x1babb0,{b1784d3f-8115-4763-13aa-32eddb68294a},0x49907ec) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1babb0) refcount=6 0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0x32dc39 ip=0032dc39 tid=0024 0024:trace:seh:raise_exception info[0]=00000001 0024:trace:seh:raise_exception info[1]=00000000 0024:trace:seh:raise_exception eax=00000000 ebx=5403fd31 ecx=54008b30 edx=0499076d esi=0032dc48 edi=00000000 0024:trace:seh:raise_exception ebp=04990768 esp=0032db9c cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202 ... --- snip --- Managed backtrace: --- snip --- System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.Windows.Media.Composition.DUCE.UnsafeNativeMethods.MilResource_SendCommandBitmapSource(ResourceHandle handle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap, Boolean systemMemoryBitmap, IntPtr pChannel) at System.Windows.Media.Composition.DUCE.Channel.SendCommandBitmapSource(ResourceHandle imageHandle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap, Boolean systemMemoryBitmap) at System.Windows.Media.Imaging.BitmapSource.UpdateBitmapSourceResource(Channel channel, Boolean skipOnChannelCheck) at System.Windows.Media.Imaging.BitmapSource.UpdateResource(Channel channel, Boolean skipOnChannelCheck) at System.Windows.Media.Imaging.BitmapSource.AddRefOnChannelCore(Channel channel) at System.Windows.Media.Imaging.BitmapSource.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel) at System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel) at System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean isOnChannel) at System.Windows.Media.Visual.UpdateContent(RenderContext ctx, VisualProxyFlags flags, Boolean isOnChannel) at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx) --- snip --- I'm a bit out of ideas now ... even if IMILBitmapSource seems pretty similar to IWICBitmapSource, some internal representation seems different. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #11 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-04-15 23:59:23 CDT --- Created attachment 44194 --> http://bugs.winehq.org/attachment.cgi?id=44194 IMILBitmapSource forwarding implementation Attached IMILBitmapSource forwarding implementation seems to work, but the app now crashes with: Unhandled Exception: System.OverflowException: The image data generated an overflow during processing. ---> System.ArithmeticException: Overflow or underflow in the arithmetic operation. --- End of inner exception stack trace --- at MS.Internal.HRESULT.Check(Int32 hr) at System.Windows.Media.Composition.DUCE.Channel.SendCommandBitmapSource(ResourceHandle imageHandle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap, Boolean systemMemoryBitmap) ... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #12 from Anastasius Focht <focht(a)gmx.net> 2013-04-16 02:01:06 CDT --- Hello Dmitry, your patch is obviously better to work with, thanks ;-) --- quote --- Unhandled Exception: System.OverflowException: The image data generated an overflow during processing. ---> System.ArithmeticException: Overflow or underflow in the arithmetic operation. --- quote --- The exception is thrown when no suitable pixelformat has been found in IMILBitmapImpl_GetPixelFormat(). MIL substracts 1 from the returned pixelformat enum value and checks against [0..max-1] pixelformat enum range. If the default value "don't care" (=0) is returned it becomes negative. This seems reasonable as it needs a specific format for further operations. --- snip --- if (IsEqualIID(&pixel_fmt_map[i].WIC_format, &This->pixelformat)) --- snip --- Both params are REFGUID. This works for me and the correct pixelformat 15 (GUID_WICPixelFormat32bppBGRA) is returned: --- snip --- if (IsEqualGUID(pixel_fmt_map[i].WIC_format, &This->pixelformat)) ... --- snip --- Anyway it ends at the same place where I currently stay. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #13 from Vincent Povirk <madewokherd(a)gmail.com> 2013-04-18 16:34:27 CDT --- Created attachment 44212 --> http://bugs.winehq.org/attachment.cgi?id=44212 a test to figure out the iface signatures The interface appears to have two more methods than IWICBitmapSource, one taking a single argument and one taking 3 arguments, as determined by this excessively terrible python script. Between observing the behavior of the calling code with stub methods and black box testing of the interface, we should be able to figure this out. Unless your current crash isn't caused by this interface at all. (I'm not in a position to run the code that's hitting this, but I may write some tests later.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #14 from Anastasius Focht <focht(a)gmx.net> 2013-04-19 05:22:18 CDT --- Hello folks, --- quote --- The interface appears to have two more methods than IWICBitmapSource, one taking a single argument and one taking 3 arguments, as determined by this excessively terrible python script. --- quote --- The missing method where it currently crashes has indeed one argument. It looks like an out pointer as this memory is later accessed by WPF. Creating a stub method and returning infamous 0xdeadbeef results in another crash: --- snip --- $ WINEDEBUG=+tid,+seh,+snoop,+wincodecs wine ./WineTest.exe ... 0024:trace:wincodecs:BitmapImpl_CopyPixels (0x1ce114,0x32dc44,4,4,0x84ce6c) 0024:CALL wpfgfx_v0300.MILQueryInterface(001ce114,0032dc34,0032dc9c) ret=042f123d 0024:trace:wincodecs:BitmapImpl_QueryInterface (0x1ce114,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce114) refcount=4 0024:RET wpfgfx_v0300.MILQueryInterface() retval=00000000 ret=042f123d 0024:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check return>) ret=042f23d7 0024:trace:wincodecs:IMILBitmapImpl_GetPixelFormat (0x1ce110,0x32dbc4) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce114) refcount=5 0024:trace:wincodecs:BitmapImpl_GetSize (0x1ce114,0x32dbb4,0x32dbb0) 0024:trace:wincodecs:BitmapImpl_GetResolution (0x1ce114,0x32dc40,0x32dc38) 0024:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce110,0x32db90) 0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0x5403f9dc ip=5403f9dc tid=0024 0024:trace:seh:raise_exception info[0]=00000000 0024:trace:seh:raise_exception info[1]=deadbeef 0024:trace:seh:raise_exception eax=deadbeef ebx=001ce110 ecx=00000000 edx=7bce4108 esi=00000000 edi=00000000 0024:trace:seh:raise_exception ebp=0032db88 esp=0032db7c cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 0024:trace:seh:call_stack_handlers calling handler at 0x7a00a2e7 code=c0000005 flags=0 0024:trace:seh:call_stack_handlers handler at 0x7a00a2e7 returned 1 0024:trace:seh:call_stack_handlers calling handler at 0x79edc3bc code=c0000005 flags=0 0024:trace:seh:call_stack_handlers handler at 0x79edc3bc returned 1 0024:trace:seh:call_stack_handlers calling handler at 0x79f908a2 code=c0000005 flags=0 --- snip --- The caller code (eax -> 0xdeadbeef returned from iface "unknown" method): --- snip --- Wine-dbg>disas 0x5403f9d9: movl 0x8(%ebp),%eax 0x5403f9dc: movl 0x0(%eax),%ecx 0x5403f9de: pushl %eax 0x5403f9df: call *0x4(%ecx) 0x5403f9e2: movl 0x8(%ebp),%eax 0x5403f9e5: movl 0x0(%eax),%ecx 0x5403f9e7: pushl %eax 0x5403f9e8: call *0x4(%ecx) 0x5403f9eb: movl 0xc(%ebp),%eax 0x5403f9ee: movl 0x8(%ebp),%ecx --- snip --- Looks pretty much like another interface/vtable, second method being called. So I went forward and created another simple IUnknown based interface without any additional methods and returned that. Yay, it went much further ... but still crashed at some point :| Interestingly only AddRef() and Release() are called (pairwise) which seems reinforce the assumption that this might be indeed IUnknown based. But strangely no QueryInterface() call? --- snip --- $ WINEDEBUG=+tid,+seh,+snoop,+wincodecs wine ./WineTest.exe ... 0024:CALL wpfgfx_v0300.MILQueryInterface(001ce468,0032dc34,0032dc9c) ret=042f123d 0024:trace:wincodecs:BitmapImpl_QueryInterface (0x1ce468,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=4 0024:RET wpfgfx_v0300.MILQueryInterface() retval=00000000 ret=042f123d 0024:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check return>) ret=042f23d7 0024:trace:wincodecs:IMILBitmapImpl_GetPixelFormat (0x1ce460,0x32dbc4) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=5 0024:trace:wincodecs:BitmapImpl_GetSize (0x1ce468,0x32dbb4,0x32dbb0) 0024:trace:wincodecs:BitmapImpl_GetResolution (0x1ce468,0x32dc40,0x32dc38) 0024:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce460,0x32db90) 0024:trace:wincodecs:IMILUnknown1Impl_AddRef (0x1ce464) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=6 0024:trace:wincodecs:IMILUnknown1Impl_AddRef (0x1ce464) 0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=7 0024:trace:wincodecs:IMILUnknown1Impl_Release (0x1ce464) 0024:trace:wincodecs:BitmapImpl_Release (0x1ce468) refcount=6 0024:trace:wincodecs:BitmapImpl_Release (0x1ce468) refcount=5 0024:RET wpfgfx_v0300.MilResource_SendCommandBitmapSource(00000010,001ce460,00000001,00000001,001a7858) retval=00000000 ret=042f23d7 0024:CALL wpfgfx_v0300.MilCompositionEngine_ExitCompositionEngineLock() ret=042f08c3 0024:RET wpfgfx_v0300.MilCompositionEngine_ExitCompositionEngineLock() retval=00000000 ret=042f08c3 0024:CALL wpfgfx_v0300.MilChannel_BeginCommand(001a7858,0032da6c,0000000c,00000030) ret=04dce89e 0024:RET wpfgfx_v0300.MilChannel_BeginCommand() retval=00000000 ret=04dce89e 0024:CALL wpfgfx_v0300.MilChannel_AppendCommandData(001a7858,0083f888,00000008) ret=04dcea12 0024:RET wpfgfx_v0300.MilChannel_AppendCommandData() retval=00000000 ret=04dcea12 0024:CALL wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock() ret=042f08c3 ... 0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032deb4,00000010,001a7858) ret=046790e0 0024:RET wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0 0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032df20,00000010,001a7858) ret=046790e0 0024:RET wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0 0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032df8c,00000010,001a7858) ret=046790e0 0024:RET wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0 0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032dff8,00000010,001a7858) ret=046790e0 0024:RET wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0 0024:CALL wpfgfx_v0300.MilChannel_CommitChannel(001a7858) ret=0467924c 0024:RET wpfgfx_v0300.MilChannel_CommitChannel() retval=00000000 ret=0467924c 0024:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a7858) ret=0467945c 0027:trace:seh:raise_exception code=c0000005 flags=0 addr=0x5404056b ip=5404056b tid=0027 0027:trace:seh:raise_exception info[0]=00000000 0027:trace:seh:raise_exception info[1]=00000009 0027:trace:seh:raise_exception eax=00000005 ebx=00000000 ecx=0497cc48 edx=54009440 esi=001ce46c edi=048de5bc 0027:trace:seh:raise_exception ebp=048de590 esp=048de588 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 0027:trace:seh:call_stack_handlers calling handler at 0x7bc982ed code=c0000005 flags=0 ... Unhandled exception: page fault on read access to 0x00000009 in 32-bit code (0x5404056b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:5404056b ESP:048de588 EBP:048de590 EFLAGS:00010206( R- -- I - -P- ) EAX:00000005 EBX:00000000 ECX:0497cc48 EDX:54009440 ESI:001ce46c EDI:048de5bc Stack dump: 0x048de588: 001ce46c 0497cc48 048de5a4 540405a8 0x048de598: 048de5bc 00000000 0497ac00 048de604 0x048de5a8: 54040140 048de5d0 0497ac00 00000000 0x048de5b8: 0497e500 00000000 00000000 00000000 0x048de5c8: 43a18000 43a18000 7f7fffff 7f7fffff 0x048de5d8: 048de610 00000005 00000000 00000000 000c: sel=0067 base=00000000 limit=00000000 32-bit r-x Backtrace: =>0 0x5404056b in wpfgfx_v0300 (+0x4056b) (0x048de590) 1 0x540405a8 in wpfgfx_v0300 (+0x405a7) (0x048de5a4) 2 0x54040140 in wpfgfx_v0300 (+0x4013f) (0x048de604) 3 0x540400bb in wpfgfx_v0300 (+0x400ba) (0x048de6a8) 4 0x54015944 in wpfgfx_v0300 (+0x15943) (0x048de6d8) --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #15 from Anastasius Focht <focht(a)gmx.net> 2013-04-19 05:31:24 CDT --- Created attachment 44216 --> http://bugs.winehq.org/attachment.cgi?id=44216 Enhanced version based on Dmitry's patch with unknown method/interface added I attached an enhanced version based on Dmitry's patch with unknown method/interface added, also including pixel format GUID comparison fix. Still lots of uncertainty but at least it goes a bit further. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #16 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44194|0 |1 is obsolete| | --- Comment #17 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-04-22 02:10:56 CDT --- Created attachment 44249 --> http://bugs.winehq.org/attachment.cgi?id=44249 IMILBitmapSource forwarding implementation (try3) This version of the implementation includes a test to play with, also it simplifies a bit COM interface definitions by using standard macros. Now the app goes even further. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #18 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-04-22 02:17:14 CDT --- Also MIL pixel format enums seem to be documented here: http://msdn.microsoft.com/en-us/library/dd341790.aspx Although there is no mention of where they are actually used, or what MIL abbreviation stands for. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #19 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #20 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-04-23 01:03:48 CDT --- (In reply to comment #19)
Hmm... it still crashes here at the same place as my v2 patch in my previous comment (caused by different BitmapImpl layout).
Looks like the differences observed are caused by the fact that we use different versions of .NET. I used 'winetricks dotnet35', while it seems that your version is 3.0. Also your backtraces indicate a crash in wpfgfx_v0300, while I have crashes in milcore.dll. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44216|0 |1 is obsolete| | --- Comment #21 from Anastasius Focht <focht(a)gmx.net> 2013-04-23 15:51:33 CDT --- Created attachment 44273 --> http://bugs.winehq.org/attachment.cgi?id=44273 Patch "v4" based on Dmitry's "try3" with additional unknown interface/method stub added and BitmapImpl layout tweak Hello Dmitry, --- quote --- Looks like the differences observed are caused by the fact that we use different versions of .NET. I used 'winetricks dotnet35', while it seems that your version is 3.0. Also your backtraces indicate a crash in wpfgfx_v0300, while I have crashes in milcore.dll. --- quote --- Actually I was working with a .NET Framework 3.5 SP1 WINEPREFIX (even if the crash backtraces suggest something with "3.0"). I created more prefixes for testing: .NET 3.0 .NET 3.0 SP1 .NET 3.5 (winetricks install currently broken, recent msxml3 regression/new bug? Needs native msmlx3 now) .NET 3.5 SP1 (same as .NET 3.5, recreating didn't work anymore with plain winetricks recipe) To my surprise your patch combined with my findings _already_ worked in a .NET 3.0 prefix. The WPF test application shows the "beta" picture. Yay! It's .NET 3.5 SP1 MIL that seems to behave differently and needs further investigation (different engine/usage?). I attached a new version "v4" patch based on your "try3" with my findings. The method stub "IMILUnknown2Impl_UnknownMethod1" has to return something different than S_OK, otherwise it crashes in all 3.x prefixes. Can you test it with your installation? At least we've got something with surprisingly little implementation effort. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #22 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-04-23 20:08:06 CDT --- (In reply to comment #21)
To my surprise your patch combined with my findings _already_ worked in a .NET 3.0 prefix. The WPF test application shows the "beta" picture. Yay!
It's .NET 3.5 SP1 MIL that seems to behave differently and needs further investigation (different engine/usage?).
I attached a new version "v4" patch based on your "try3" with my findings. The method stub "IMILUnknown2Impl_UnknownMethod1" has to return something different than S_OK, otherwise it crashes in all 3.x prefixes.
Can you test it with your installation? At least we've got something with surprisingly little implementation effort.
Heh, it also works here showing the "Beta" image! Impressive work as always Anastasius :) I suppose v4 patch is still not ready to be sent for inclusion yet, since 3.5 SP1 needs more work. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #23 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-04-24 02:54:11 CDT --- (In reply to comment #21)
Created attachment 44273 [details] Patch "v4" based on Dmitry's "try3" with additional unknown interface/method stub added and BitmapImpl layout tweak
typedef struct BitmapImpl { + IMILUnknown1 IMILUnknown1_iface; + void *dummy1; + IMILBitmapSource IMILBitmapSource_iface; IWICBitmap IWICBitmap_iface; + IMILUnknown2 IMILUnknown2_iface; LONG ref; IWICPalette *palette; int palette_set;
Testing shows that dummy1 is really a refcount, and all 4 interfaces respond to QI with IID_IUnknown, IID_IWICBitmap, IID_IWICBitmapSource, IID_IMILBitmap and IID_IMILBitmapSource, returning the same iface pointers. They do not respond to other IID_IMIL* ids (that could be found in PSDK's uuid.lib): IID_IMILBitmapLock, IID_IMILBitmapScaler, IID_IMILBitmapConverter and IID_IMILPalette. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jitsumi(a)gmail.com --- Comment #24 from Dan Kegel <dank(a)kegel.com> 2013-04-25 21:54:01 CDT --- *** Bug 32906 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #25 from leon <leonidbrook(a)gmail.com> 2013-05-08 07:40:45 CDT --- Impressive work !! Can you please update what is the status of this bug? Is it fixed for .NET 3.5 or .NET 4.0 ? Is the fix going to be included in Wine 1.6 or some earlier version? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #26 from Austin English <austinenglish(a)gmail.com> 2013-05-08 12:37:55 CDT --- (In reply to comment #25)
Impressive work !!
Can you please update what is the status of this bug? Is it fixed for .NET 3.5 or .NET 4.0 ? Is the fix going to be included in Wine 1.6 or some earlier version?
It's not yet fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #27 from Anastasius Focht <focht(a)gmx.net> 2013-05-09 12:50:46 CDT --- Hello folks, maybe Dmitry can attach a cleaned up version, incorporating his additional findings (comment #23) which should work for WPF 3.0 and 3.5 Though 3.5 SP1 behaviour still needs to be investigated ... WPF 4.x doesn't seem have any problems connected to this bug (windowscodecs interfaces), most likely due to different engines/code rewrite. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #28 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-05-10 22:51:02 CDT --- (In reply to comment #27)
maybe Dmitry can attach a cleaned up version, incorporating his additional findings (comment #23) which should work for WPF 3.0 and 3.5
The only change I did is replacing 'dummy1' by 'ref'. Probably your v4 variant with this change could be sent to wine-patches + some other minor clean ups. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Egor <to_egor(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |to_egor(a)hotmail.com --- Comment #29 from Egor <to_egor(a)hotmail.com> 2013-07-02 06:17:01 CDT --- Hi, all. Perhaps I have same problem with my application using dynamic array via RPC. I suppose the core of the problem is in corruption of internal Wine's data during memory freeing. I created topic in the forum - http://forum.winehq.org/viewtopic.php?f=8&t=19251 I hope my info help developers to fix the bug faster. Excuse me, if I mistake. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 swdevelop1981(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |swdevelop1981(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #30 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2013-10-18 21:36:12 CDT --- 5e78e0b695c91041d2f034b8cc9409bf4bd37144 could be considered a first draft that has been committed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5e78e0b695c91041d2f034b8cc9 | |409bf4bd37144 Status|NEW |RESOLVED Resolution| |FIXED --- Comment #31 from Anastasius Focht <focht(a)gmx.net> 2013-10-19 04:54:38 CDT --- Hello folks, I think the initial goal to get the example app work with Wine builtin windowscodecs has been met. The example works for .NET Framework 3.0 and 3.5 Different behaviour for .NET Framework 3.5 SP1 MIL deserves its own bug. Fixed by commit http://source.winehq.org/git/wine.git/commitdiff/5e78e0b695c91041d2f034b8cc9... Thanks Dmitry. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 --- Comment #32 from Anastasius Focht <focht(a)gmx.net> 2013-10-19 05:17:20 CDT --- Hello folks, created bug 34764 for crash in .NET Framework 3.5 SP1 Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #33 from Alexandre Julliard <julliard(a)winehq.org> 2013-10-25 12:54:28 CDT --- Closing bugs fixed in 1.7.5. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33384 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i30817(a)gmail.com --- Comment #34 from Anastasius Focht <focht(a)gmx.net> 2013-11-17 15:14:34 CST --- *** Bug 34937 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org