[Bug 56182] New: Regression: Hang during exist in Paint Shop Pro 9.01
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(a)winehq.org Reporter: kle(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 C. Leu <kle(a)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 | -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 Zeb Figura <z.figura12(a)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(a)gmail.com Keywords| |regression --- Comment #1 from Zeb Figura <z.figura12(a)gmail.com> --- In what version of Wine did this work? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 Austin English <austinenglish(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #2 from C. Leu <kle(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #3 from C. Leu <kle(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |9562e818101e67304c613dec922 | |b86a793c26e59 CC| |bernhardu(a)mailbox.org --- Comment #4 from Bernhard Übelacker <bernhardu(a)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(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #5 from Bernhard Übelacker <bernhardu(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #6 from C. Leu <kle(a)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.) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 C. Leu <kle(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 C. Leu <kle(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #7 from Bernhard Übelacker <bernhardu(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #8 from C. Leu <kle(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Component|ntdll |ole32 --- Comment #9 from Zeb Figura <z.figura12(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #10 from Zeb Figura <z.figura12(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #11 from C. Leu <kle(a)bluewin.ch> --- Many thanks Zeb Figura for your additional research in this topic. For Wine 10.0-rc6 I can confirm that the problem is of course still present but it looks that PSP9 exits normally when it is closed right after it is started. No idea if this has any relevance and no idea if this was also the case with previous Wine releases. Additionally I have checked the "legacy Windows" program behavior of PSP9 by installing it into a different Wine prefix which was set to "Windows ME". A simple Windows override of an existing PSP9 Wine prefix does not work because the PSP9 "NT" program dll files are Unicode based while those for Windows ME / 98SE are only ANSI compliant. This results in a program crash of PSP9 when it was installed originally in a "Windows NT" prefix which was then changed to a legacy Windows variant. However, an install into a legacy "Windows ME" Wine prefix works fine and this prefix can be set later also to an NT based Windows version without any program crash. But unfortunately regarding the issue reported here a change to a legacy Windows variant didn't help because Wine is still acting like a "Windows NT" install even when it set to "Windows ME". Perhaps this workaround could work at an super-old "antique" Wine build which follows more the "Windows DOS" kernel behavior rather than the NT kernel one. ;-) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56182 --- Comment #12 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to C. Leu from comment #11)
Many thanks Zeb Figura for your additional research in this topic.
For Wine 10.0-rc6 I can confirm that the problem is of course still present but it looks that PSP9 exits normally when it is closed right after it is started. No idea if this has any relevance and no idea if this was also the case with previous Wine releases.
This is probably because of the mentioned 5 second timeout. If you close less than 5 seconds after opening, I think that will just work without hanging.
Additionally I have checked the "legacy Windows" program behavior of PSP9 by installing it into a different Wine prefix which was set to "Windows ME". A simple Windows override of an existing PSP9 Wine prefix does not work because the PSP9 "NT" program dll files are Unicode based while those for Windows ME / 98SE are only ANSI compliant. This results in a program crash of PSP9 when it was installed originally in a "Windows NT" prefix which was then changed to a legacy Windows variant.
However, an install into a legacy "Windows ME" Wine prefix works fine and this prefix can be set later also to an NT based Windows version without any program crash.
But unfortunately regarding the issue reported here a change to a legacy Windows variant didn't help because Wine is still acting like a "Windows NT" install even when it set to "Windows ME". Perhaps this workaround could work at an super-old "antique" Wine build which follows more the "Windows DOS" kernel behavior rather than the NT kernel one. ;-)
No idea what this is about, but it's probably unrelated. -- 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)
-
WineHQ Bugzilla