https://bugs.winehq.org/show_bug.cgi?id=49598
Bug ID: 49598 Summary: ProtectionID v6.9.0 chokes on steam_api.dll while scanning Product: Wine Version: 5.2 Hardware: x86 URL: https://protectionid.net/ OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: sagawa.aki+winebugs@gmail.com Regression SHA1: 08bf605acb4d319e016a7eafe0c675509445bd4a Distribution: ---
There may exist other files to trigger this bug, I noticed this while checking some of my Steam games with PiD 6.9.0. When the file steam_api.dll is being analyzed by PiD, the application seems to come into an infinite loop while using 100% CPU. As a result, scanning this particular file never finishes. The program interface is still responding so it's not hung completely. Nothing relevant in the terminal.
To reproduce: Unrar and start Protection_ID.eXe, click the <Scan> button, <Single File> and browse for an existing steam_api.dll (majority of Steam games have one). Status shows "Steam Scan..." but scanning is never completed.
The problem was introduced by https://source.winehq.org/git/wine.git/commit/08bf605acb4d319e016a7eafe0c675...
The bug doesn't occur with the previous commit.
Protection_ID.eXe md5sum: ce07e32f2e9b56d8c60ef9f4ada9e352
wine-5.13-38-ga455ff61b4
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #1 from Sagawa sagawa.aki+winebugs@gmail.com --- Thanks for reporting. Could you tell me what locale you are using? Since wsprintfA is an ANSI version function, its behavior depends on your locale settings aka ANSI codepage.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Sagawa from comment #1)
Thanks for reporting. Could you tell me what locale you are using? Since wsprintfA is an ANSI version function, its behavior depends on your locale settings aka ANSI codepage.
LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=en_US.UTF-8 LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #3 from Sagawa sagawa.aki+winebugs@gmail.com --- This issue might be related to compiler's optimization. With -O2 binary and no WINEDEBUG, I can reproduce the issue. But, with either -O0 binary or WINEDEBUG=string, I can't reproduce the issue. I tried with gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0 on Ubuntu 20.04.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #4 from Sagawa sagawa.aki+winebugs@gmail.com --- Created attachment 67825 --> https://bugs.winehq.org/attachment.cgi?id=67825 Proposed patch
Could you try this patch?
Reading the code, I found another issue in the code. After fixing it, this issue doesn't happen, too.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Sagawa from comment #4)
Created attachment 67825 [details] Proposed patch
Could you try this patch?
Reading the code, I found another issue in the code. After fixing it, this issue doesn't happen, too.
The patch doesn't fix the problem for me, using GCC 10.1 on Arch Linux. Wine was compiled with -O2.
Sure enough, the bug doesn't appear with -O0.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #6 from Sagawa sagawa.aki+winebugs@gmail.com --- Does it happen with Arch Linux's package? On my environment, the scan completed without the issue. I built up Arch Linux on my VirtualBox and tested its package, wine 5.13-1.
The scan also ran smoothly with git version, wine-5.13-268-gb7e51a1653, without my patch with gcc 10.1.0-2.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #7 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Sagawa from comment #6)
Does it happen with Arch Linux's package? On my environment, the scan completed without the issue. I built up Arch Linux on my VirtualBox and tested its package, wine 5.13-1.
The scan also ran smoothly with git version, wine-5.13-268-gb7e51a1653, without my patch with gcc 10.1.0-2.
The problem also happens for me with original Wine versions from the Arch repos: wine-5.13-1 wine-staging-5.13-1
I have no idea what might be configured differently on my machine causing this issue.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #8 from Sagawa sagawa.aki+winebugs@gmail.com --- I examined PiD behavior and it looks that this is a PiD's bug.
When PiD analyzes steam_api.dll, wsprintfA() is called at 0044710Eh without preserving ECX register. Since wsprintfA() is a WINAPIV (aka __cdecl) function, it doesn't keep ECX register and overwrites the value inside it. So, afterwards, at 0044722dh, LOOP instruction doesn't work as expected because it depends on the past ECX value.
https://bugs.winehq.org/show_bug.cgi?id=49598
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- Would it make sense to keep the register regardless, to make buggy programs like that happy? We have that at other places already, but I'm not sure about the rules.
https://bugs.winehq.org/show_bug.cgi?id=49598
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |z.figura12@gmail.com CC| |z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- I don't think there's actually a Wine bug here.
If I manually poke various values into %ecx at the end of wsprintfA(), the program will essentially hang on the "Steam Scan" step for some amount of time. E.g. if %ecx = 0, it hangs for about 6 seconds, if %ecx = 1, it doesn't hang, if %ecx = 0x80000000, it hangs for about 3 seconds. This would be consistent with some loop executing %ecx times.
Moreover, though, I manually tried calling wsprintfA() on Windows, with the exact same parameter values, and it didn't preserve %ecx—it set it to some random value relatively high in the memory space. Running the program with steam_api.dll caused it to hang in the "Steam Scan" for about 5 seconds.
Béla, does the program hang forever for you? If not, and you can reproduce similar behaviour, I think this is an application bug, not a Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=49598
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- FWIW, this works again, tested with wine-6.0-rc2-52-g0aa6f8e2ea1. This was fixed for me with commit 9cc92365560f19c2fd2b9796f79aa75e02381bb1 (user32: Build with msvcrt.). Does that qualify as fixed, Zebediah? Feel free to resolve as invalid, however, if you think that's more appropriate.
https://bugs.winehq.org/show_bug.cgi?id=49598
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #12 from Zebediah Figura z.figura12@gmail.com --- (In reply to Béla Gyebrószki from comment #11)
Does that qualify as fixed, Zebediah? Feel free to resolve as invalid, however, if you think that's more appropriate.
I think it's an application bug, and only happens to work by chance. The only reason I'm not sure about that is that your original report seems to imply that it hangs forever, rather than (as for me) a few seconds. If you think it's worth retesting, and can reproduce an infinite hang, please feel free to reopen.
https://bugs.winehq.org/show_bug.cgi?id=49598
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|https://protectionid.net/ |https://web.archive.org/web | |/20180909104700/https://pid | |.wiretarget.com/?f=Protecti | |onId.690.December.2017.rar CC| |focht@gmx.net
-
WineHQ Bugzilla