https://bugs.winehq.org/show_bug.cgi?id=56182
Bug ID: 56182 Summary: Regression: Hang during exist in Paint Shop Pro 9.01 Product: Wine Version: 9.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: kle@bluewin.ch Distribution: ---
Created attachment 75895 --> https://bugs.winehq.org/attachment.cgi?id=75895 Painnt Shop Pro 9 CLI output
Hi all
I have tested Paint Shop Pro 9 with Wine 9.0-rc5 and it works almost perfectly fine. This program is listed in Wine's AppDB as "Platinum" unfortunately there exist one regression.
It is not possible to exit the program properly. If it is started via the CLI and then closed there appears as the last information an "0178:err:sync:RtlpWaitForCriticalSection section 7BD7B2C0 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0178, blocked by 0024, retrying (60 sec)" message. That one is repeating itself after one minute. As a result the CLI window must be forcefully closed which then also terminates the Wine session.
See the "PaintShopPro9_CLI_output.txt" for more information.
There is only one override regarding the "gdiplus.dll" file needed at least for the first startup. Otherwise it is not possible to close the "Learning center" dialog box. When that is done the override can be reverted I think. Note, Paint Shop Pro 9 already contains an own (quite old) native "gdiplus.dll" file.
The program can be downloaded from here: https://www.tenforums.com/software-apps/191499-paint-shop-pro-4-12-7-04-8-1-...
It can be installed via the "Jasc Paint Shop Pro 9.msi" and "Jasc Animation Shop 3.msi" files without any registration and also without any serial.
https://bugs.winehq.org/show_bug.cgi?id=56182
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Regression: Hang during |Regression: Hang during |exist in Paint Shop Pro |exit in Paint Shop Pro 9.01 |9.01 |
https://bugs.winehq.org/show_bug.cgi?id=56182
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Regression: Hang during |Paint Shop Pro 9.01 hangs |exit in Paint Shop Pro 9.01 |on exit CC| |z.figura12@gmail.com Keywords| |regression
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- In what version of Wine did this work?
https://bugs.winehq.org/show_bug.cgi?id=56182
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.tenforums.com/s | |oftware-apps/191499-paint-s | |hop-pro-4-12-7-04-8-1-9-01- | |a.html Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #2 from C. Leu kle@bluewin.ch --- I have tried this only recently and didn't test this with several other Wine versions. So this could be a longer ago "introduced" regression.
I looks that this seems to have worked for super old Wine 1.7.20. There is at least no information posted about any hang in the Wine PSP9 AppDB test result.
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #3 from C. Leu kle@bluewin.ch --- A short addition.
There exist a similar problem during the exit process with the Autodesk Fusion 360 application. Yeah, it is highly unlikely that those issues are related simply because of the age. PaintShop Pro 9 is around 20 years old while Fusion 360 is a present-day application.
Nevertheless it could makes sense to test the open "Collection of small fixes for Fusion 360" Wine MR with PSP9. I think especially the "Windowing behavior" of the "Learning center" could be improved by that. (And finally even Paint.NET could benefit from that MR but that's again another story.)
https://gitlab.winehq.org/wine/wine/-/merge_requests/2343
I would try this myself but unfortunately I am not fit enough in building Wine at my own. ;-)
More information about the Autodesk Fusion 360 behavior in Wine can be found here:
https://github.com/cryinkfly/Autodesk-Fusion-360-for-Linux/issues/311
https://bugs.winehq.org/show_bug.cgi?id=56182
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |9562e818101e67304c613dec922 | |b86a793c26e59 CC| |bernhardu@mailbox.org
--- Comment #4 from Bernhard Übelacker bernhardu@mailbox.org --- I tried to do a git bisect it points to (inside a Debian jessie VM): 9562e818101e67304c613dec922b86a793c26e59 is the first broken commit commit 9562e818101e67304c613dec922b86a793c26e59 Author: Sebastian Lackner sebastian@fds-team.de Date: Sun Jul 26 23:24:06 2015 +0200
ntdll: Reimplement RtlQueueWorkItem on top of new threadpool API.
The first release including this commit is wine-1.7.48.
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #5 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75925 --> https://bugs.winehq.org/attachment.cgi?id=75925 Revert commit 9562e818101 with recent git.
To my surprise this commit could be reverted with recent git without much effort, attached for convenience. With it the hang does not show up.
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #6 from C. Leu kle@bluewin.ch --- Thanks Bernhard Übelacker for the bisection of the hang. This is really a nice finding.
Whatever, apart from the hang on exit PSP9 Pro really works amazing. And it runs interestingly better with the built-in gdiplus file than with the native one. There seems to exist only a minor flaw with selections. The screen-output freezes for a short time after a selected area is moved for more than two or three pixels. This is true for both, built-in and native. But that's another problem for which I may probably open an new issue report. ;-)
And yeah the printing function seems to be non-functional. PSP9 Pro is complaining about a missing mfc42.dll file but it even does not print when it has a native one. (Could be another regression as no such issue was reported for Wine 1.7.20.)
https://bugs.winehq.org/show_bug.cgi?id=56182
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll
https://bugs.winehq.org/show_bug.cgi?id=56182
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #7 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Bernhard Übelacker from comment #5)
Revert commit 9562e818101 with recent git.
... With it the hang does not show up.
As I did some testing with this application for another bug, the hang still showed up sometimes with above reverting patch, but a lot less likely.
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #8 from C. Leu kle@bluewin.ch --- A short update to this topic.
I have tested Wine 9.19 and the issue is still present. The error output is also the same.
However, regarding the other mentioned "printing issue" of Paint Shop Pro 9.01 on more recent Wine versions it seems to be resolved, so will close bug 56219.
https://bugs.winehq.org/show_bug.cgi?id=56182
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Component|ntdll |ole32
--- Comment #9 from Zeb Figura z.figura12@gmail.com --- The application releases a proxy (IWiaDevMgr) from DllMain (DLL_PROCESS_DETACH, invoked through manual FreeLibrary()). This happens at a time when there are no threadpool threads active (and in practice any threads—such as the ones spawned earlier while creating or using the same proxy—have shut down due to the 5 second timeout.)
Calling a proxy method under normal circumstances requires an extra thread, which we wait for synchronously. This is because I_RpcSendReceive() [at least our understanding of it] is synchronous and encompasses the whole send/receive process, but we need the calling thread to be calling CoWaitForMultipleHandles().
This means we try to create and wait for a thread from DllMain(), which doesn't work. Manual testing confirms this part, and it also confirms that using RtlQueueWorkItem() on Windows doesn't work either.
Some tests show that you can do an arbitrary number of simultaneous proxy calls from within DllMain(), and they don't deadlock. This means one of three things that I can think of:
* Native is pre-allocating a new thread for each thread that has a proxy. This could be tested using thread reflection APIs, but I worry this comes too close to testing implementation details.
* Native is somehow interrupting the thread to perform reentrant calls. It's not through user APCs (I checked and manually created ones don't get delivered). It could be through suspension and debugging APIs, though this seems a bit less likely...
* Native is not using a separate thread.
Conceptually, this is the easiest and best solution. We are performing two waits here—one on a named pipe [which is supposed to be an LPC port on Windows, but this doesn't matter], and one for window message. Combining these waits is easy enough under normal circumstances; we could e.g. do async I/O on the pipe and use CoWaitForMultipleHandles(). [I don't know if an LPC port is similarly waitable...]
The problem is the rpcrt4 interface. I have no idea how to *do* this with rpcrt4. There is an async call interface, but I don't see any way to get a waitable handle out of it. But rpcrt4 is full of magic hidden glue, and there could easily be all number of secret incantations that ole32 is performing. I just don't see any obvious ones.
I'd like to be able to do something here, but I just can't without further direction.
https://bugs.winehq.org/show_bug.cgi?id=56182
--- Comment #10 from Zeb Figura z.figura12@gmail.com --- I suppose there is also a fourth option, which is that ole32 just doesn't use rpcrt4 at all, and does everything itself. I don't find it more appealing than the other options, but it's there.
-
WineHQ Bugzilla