https://bugs.winehq.org/show_bug.cgi?id=55513
Bug ID: 55513 Summary: Paint.NET 3.5.11 runs unstable on Wine 8.x devel releases Product: Wine Version: 8.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs@winehq.org Reporter: kle@bluewin.ch Distribution: ---
Created attachment 75077 --> https://bugs.winehq.org/attachment.cgi?id=75077 Paint.NET 3.5.11 crash report
There seems to be a regression regarding the built-in gdiplus.dll in more recent Wine 8.x devel builds.
Unfortunately Paint.NET 3.5.11 no longer runs stable. This behavior was previously known only when the native gdiplus.dll file was used. It didn't happened with the built-in one.
It looks that this instability is related to a speed improvement of the built-in gdiplus.dll.
In older Wine versions Paint.NET 3.5.11 was lagging when a line was painted but it worked stable. This lag was not present with a native gdiplus.dll file but Paint.NET crashed randomly when the native variant was used. Now Paint.NET also crashes with the built-in gdiplus.dll variant while there is no longer any lag present.
More information about that Paint.NET 3.5.11 lag issue can be found in my old bug 51561.
So in summary, Paint.NET 3.5.11 works in recent Wine 8.x devel releases faster but less stable. I think this regression was in introduced somewhere in the Wine 8.1x branch. It is confirmed for Wine 8.14 and 8.15.
Final note, it is currently not possible to install Paint.NET 3.5.11 into a fresh Wine devel prefix. The installation will fail. A workaround is to install Paint.NET 3.5.11 under Wine stable and then copy over the whole prefix to a Wine devel installation. I can confirm that this works fine for Wine 8.0.2 and Wine 8.15.
https://bugs.winehq.org/show_bug.cgi?id=55513
Bartosz gang65@poczta.onet.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gang65@poczta.onet.pl
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #1 from Bartosz gang65@poczta.onet.pl --- Are you able to check which Wine Devel release introduce that crash?
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #2 from C. Leu kle@bluewin.ch --- Unfortunately I didn't have tested the behavior of Paint.NET in Wine devel (and stable) for quite some time. I think the last time I looked into this topic was with a later Wine 7.x devel release. And for me it always worked stable with the built-in gdiplus.dll even when there was the lagging problem present.
As mentioned, the behavior is now the same as with the native gdiplus variant which always crashed Paint.NET 3.5.11 after some time.
Whatever, I have experienced another BIG surprise when I looked into Paint.NET and Wine 8.0.2 stable with a new and totally clean prefix. The lag is not there and it runs stable, no crash occurred so far. I am now somehow baffled. It looks that my old .wine_PaintNET prefix was somehow flawed?
Whatever, the last state is that the lag problem was resolved even earlier, so somewhere before Wine 8.0 stable. And it worked until some point when the built-in gdiplus.dll crash regression was introduced in Wine 8.x devel. Maybe this is in some way related to the installation problem of Paint.NET 3.5.11 in newer Wine 8.x devel releases. I have no idea.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #3 from C. Leu kle@bluewin.ch --- Created attachment 75078 --> https://bugs.winehq.org/attachment.cgi?id=75078 Paint.NET CLI output Wine 8.0.2 (no crash)
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #4 from Bartosz gang65@poczta.onet.pl --- It would be very useful if you could check in which Wine version this regression were introduced.
For Ubuntu/Debian it is possible to install previous versions of Wine: https://wiki.winehq.org/Ubuntu
More information: https://itsfoss.com/apt-install-specific-version/
https://bugs.winehq.org/show_bug.cgi?id=55513
Jeff Smith whydoubt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |whydoubt@gmail.com
--- Comment #5 from Jeff Smith whydoubt@gmail.com --- The crash report indicates that GdipCreateBitmapFromHICON is returning InvalidParameter. Based on tests, I added input validation to that function recently in commit 19b7d1dbabe75366f20eadc704109583a89f9dd7. If this happens with native gdiplus, but not on Windows, it makes we wonder if something is wrong in icon creation.
It might helpful to see a log with WINEDEBUG set to 'gdiplus,bitmap,icon,cursor'.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #6 from Jeff Smith whydoubt@gmail.com --- I reproduced the problem (with all builtin components). I collected and reviewed logs and ran some tests on Windows based on those. All of this led me to think it is not an issue with gdiplus or with icon/cursor loading.
Then I managed to get Paint.NET 3.5.11 installed along-side native .NET (3.5 SP1). This combination does not appear to have stability issues. I'm leaning toward this being a mono issue.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #7 from C. Leu kle@bluewin.ch --- Yes I can confirm this behavior. Many thanks @Jeff Smith for bisecting the problem.
Paint.NET 3.5.11 is working stable in Wine 8.15 when Mono 7.4.1 is used. Great! So I have simply uninstalled Mono 8.0.0 and then installed the older build from here:
https://github.com/madewokherd/wine-mono/releases
So should I now also close this issue here? It looks that this is a problem in Mono 8.0.0 and Mono 8.0.1.
The only last minor flaws in Paint.NET 3.5.11 is that the "miniature-view window" (on the right corner above) do not shows anything. But it starts to work when the Windows version is set to "Windows XP". But this is again another topic. ;-)
https://bugs.winehq.org/show_bug.cgi?id=55513
Bartosz gang65@poczta.onet.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #8 from Bartosz gang65@poczta.onet.pl --- Maybe @Esme Povirk could help what to do with Wine-Mono bug?
https://bugs.winehq.org/show_bug.cgi?id=55513
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Component|gdiplus |mscoree
--- Comment #9 from Esme Povirk madewokherd@gmail.com --- It should be possible to bisect Wine Mono.
https://bugs.winehq.org/show_bug.cgi?id=55513
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Paint.NET 3.5.11 runs |Paint.NET 3.5.11 runs |unstable on Wine 8.x devel |unstable on Wine 8.9 devel |releases |(and later) because of a | |bug in Mono 8.0.x
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #10 from Jeff Smith whydoubt@gmail.com --- Interesting that it worked for you under mono 7.4.1, as it still crashes for me.
Based on the crash report, I turned on tracing in Mono and learned a bit more.
- The issue is triggered by moving the cursor over items in the toolbar. - In trying to display tooltips, the cursor's hotspot is checked. - The winforms implementation to get HotSpot, autoboxes and unboxes the cursor's handle (as Icon) before calling GetIconInfo on that handle. - The mono implementation of the Icon constructor calls on Bitmap.FromHicon which basically wraps GdipCreateBitmapFromHICON (which fails for cursors) and throws an exception on the InvalidParameter return status.
A couple of possible solutions: - winforms: pass the cursor's handle directly to GetIconInfo (avoid the boxing). - mono: make the Icon constructor lazy (delay creating bitmap until needed). Either or both should fix this bug, but the mono fix could potentially be a lot of work, while the winforms fix should be simple.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #11 from Nikolay Sivov bunglehead@gmail.com --- If the same happens with netcore Winforms, we should fix the real issue.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #12 from C. Leu kle@bluewin.ch --- Sorry folks here follows and important addition. ;-)
I have again re-checked the situation and in my new .wine_PaintNET prefix there are two dll overrides active, "BCP47Langs.dll" and "UIAutomationCore.dll". Those were installed "manually" by simple putting them into the Paint.NET folder.
Unfortunately I have completely forgotten about that. I think originally I have made those overrides to bring away the annoying "0108:fixme:uiautomation:UiaClientsAreListening ()" warning messages at the CLI. I didn't think that his would have any other effect.
So the situation for Wine 8.15 devel and Mono 7.4.1 is that Paint.NET 3.5.11 works with those overrides stable and fast with no lag. But when Mono 8.0.0 or 8.0.1 is installed Paint.NET crashes again, - regardless of the presence of "BCP47Langs.dll" and "UIAutomationCore.dll".
Interestingly Wine 8.0.2 stable which includes Mono 7.4.0 worked fine without any dll override. Although I don't have tested this really intensive.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #13 from C. Leu kle@bluewin.ch --- A further note, - the Windows version seems to be of great importance in this topic. As mentioned I use in my Paint.NET prefix the "Windows XP" setting which works fine. But when I set it to "Windows 7" then I can reproduce again the crash, - regardless of any dll override. Also "Windows 2003" is working fine.
So the setting of the Windows version seems to be another game changer. It looks that Paint.NET 3.5.11 uses for those pre-Vista Windows versions another code path. And I assume that this is also the reason why all Paint.NET 4.x versions are broken. Those Paint.NET builds are no longer supporting the pre-Vista Windows variants and have therefore removed any alternative code paths.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #14 from Esme Povirk madewokherd@gmail.com --- I'd be tempted to switch to using the Icon class from .NET Core, as we've done with System.Drawing.Printing classes.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #15 from Jeff Smith whydoubt@gmail.com --- I'm not entirely familiar with how all the moving parts within wine-mono, but it appears that winforms was forked from an early preview release of .NET Core 3.0 around May 2019. The last commit to Cursor.cs [1] was in May 2019. There was a change in upstream [2] to avoid the autobox/unbox in July 2019.
I'd be tempted to switch to using the Icon class from .NET Core, as we've done with System.Drawing.Printing classes.
No clue how much work that is, but doesn't sound like a bad idea.
[1]: https://github.com/madewokherd/winforms/blob/main/src/System.Windows.Forms/s... [2]: https://github.com/dotnet/winforms/commit/b5112e1a79e1a00de9c714a7c96801320c...
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #16 from C. Leu kle@bluewin.ch --- A final note about the situation in Wine 8.15 and Mono 7.4.1 with "Windows XP" setting.
It looks that also this combination doesn't runs fully stable. It is still possible to trigger the "GdipCreateBitmapFromHICON crash" when a lot of lines are drawn and alternately the cursor is moved excessively over the toolbar. But the bug happens definitely less frequently with that setup.
Ergo, when the Windows version is set to Vista or higher then the crash appears almost instantly.
So in summary it can be said that the bug is present also with older Mono versions and older Windows version settings but it occurs less often. And this may be true also for Wine 8.0.2 stable, - will check that when I find the time.
https://bugs.winehq.org/show_bug.cgi?id=55513
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Paint.NET 3.5.11 runs |Paint.NET 3.5.11 runs |unstable on Wine 8.9 devel |unstable on Wine 8.9 devel |(and later) because of a |(and later) because of a |bug in Mono 8.0.x |bug in Mono
https://bugs.winehq.org/show_bug.cgi?id=55513
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
--- Comment #17 from NSLW lukasz.wojnilowicz@gmail.com --- *** Bug 55682 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=55513
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=55513
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Paint.NET 3.5.11 runs |Paint.NET 3.5.11 runs |unstable on Wine 8.9 devel |unstable on Wine 8.x (and |(and later) because of a |later) because of a bug in |bug in Mono |Mono
https://bugs.winehq.org/show_bug.cgi?id=55513
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=55513
huntantr huntantr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |huntantr@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #18 from C. Leu kle@bluewin.ch --- Okay folks here follows some amazing news.
This bug is no longer present in Wine 9.8 and Wine Mono 9.1.0.
So it looks to be resolved? At least for me it works now properly without any crash. Instead of a crash I get when hovering over the tool icons multiple "TOOLTIPS Timer" warnings at the CLI:
0144:err:tooltips:TOOLTIPS_Timer How did this happen? 0144:err:tooltips:TOOLTIPS_Timer How did this happen? 0144:err:tooltips:TOOLTIPS_Timer How did this happen? 0144:err:tooltips:TOOLTIPS_Timer How did this happen?
But otherwise Paint.NET 3.5.11 seems to work error free.
Note, the Windows version is set to "Windows 2003" because otherwise the "preview window" (in the top right corner) is not working as it should.
Additionally I have an override active of "uiautomationcore.dll". It works also with the built-in one but then I get at the CLI a ton of:
01f8:fixme:uiautomation:UiaReturnRawElementProvider UIA-to-MSAA bridge not implemented, no provider map to free.
The last thing which could be improved in this topic seems to be gdiplus:
0144:fixme:gdiplus:brush_fill_pixels path gradient blend not implemented
Whatever, many thanks to whomever for fixing this annoying problem. :-)
https://bugs.winehq.org/show_bug.cgi?id=55513
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #19 from Ken Sharp imwellcushtymelike@gmail.com --- Fixed.
https://bugs.winehq.org/show_bug.cgi?id=55513
--- Comment #20 from C. Leu kle@bluewin.ch --- A final addition.
Paint.NET 3.5.11 also works in Wine 9.0 when Wine Mono 9.1.0 is present. I have tested it. So just uninstall any older Mono version and install a current one. This should resolve the problem then also on older Wine releases.
As mentioned, the sole and only needed workaround is to set the Windows version to 2003 (or lower). Otherwise the "preview window" (in the top right corner) of Paint.NET 3.5.11 will not work properly. I assume that issue is related to the "unimplemented Direct2D" functions problem mentioned in bug 46039 concerning newer Paint.NET 4.x releases.
https://bugs.winehq.org/show_bug.cgi?id=55513
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.9.
-
WineHQ Bugzilla