https://bugs.winehq.org/show_bug.cgi?id=55151
Bug ID: 55151 Summary: PC crashes after endlessly eating up memory Product: Wine Version: 8.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs@winehq.org Reporter: axis6404@proton.me Distribution: ---
example script (selfdel.bat):
:REP del "selfdel.bat" if exist "selfdel.bat" goto REP
wine selfdel.bat (An infinite loop occurs. Until it eats up all the memory and the PC stops.)
The koeiuc.bat in Steam games made by Koei eats up all the memory and crashes the PC.
https://bugs.winehq.org/show_bug.cgi?id=55151
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase
https://bugs.winehq.org/show_bug.cgi?id=55151
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME CC| |eric.pouech@gmail.com Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Eric Pouech eric.pouech@gmail.com --- Can no longer repro in Wine 9.12.
Closing
https://bugs.winehq.org/show_bug.cgi?id=55151
axis6404@proton.me changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|WORKSFORME |--- Status|RESOLVED |UNCONFIRMED
--- Comment #2 from axis6404@proton.me --- I checked with wine9.12 and the bug has not been fixed yet.
Notice the wineserver process. It will increase memory usage. If you run selfdel.bat in a terminal, the memory increase will be slower. doaxvv (DEAD OR ALIVE Xtreme Venus Vacation) increases memory quickly and dramatically. This is because it is not run in a terminal. Try searching for koeiuc.bat in qps or something while running doaxvv's Koei update (which happens every week).
The original MS Windows does not have the infinite loop, because "del selfdel.bat" succeeds once. The cmd.exe in wine9.12 keeps selfdel.bat open with ReadFile() and executes it. Therefore, selfdel.bat is file-locked all the way until it exits. The original MS cmd.exe does not file lock. I've heard rumors that it stores the script's execution position as a cursor with a numerical value, and each execution opens the file, reads it, closes it, executes it, opens the file, reads it, closes it, executes it, opens the file... (infinite loop)
Translated with DeepL.com (free version)
https://bugs.winehq.org/show_bug.cgi?id=55151
--- Comment #3 from axis6404@proton.me --- It is not the .bat process that increases memory. It is the "wineserver" process that increases memory.
https://bugs.winehq.org/show_bug.cgi?id=55151
--- Comment #4 from axis6404@proton.me --- It consumes very much CPU as well as memory. It is because of the infinite loop. In doaxvv, koeiuc.bat uses 100% of one core due to this bug. This high CPU usage continues until doaxvv exits.
2-core CPUs use 50% of the CPU. 4-core CPUs use 25% of the CPU. 8-core CPUs use 12.5% of the CPU.
https://bugs.winehq.org/show_bug.cgi?id=55151
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |dark.shadow4@web.de
--- Comment #5 from Fabian Maurer dark.shadow4@web.de --- I can confirm the issue, wineserver seems to infinitely grow in size, although very slowly. self-delete should probably just work.
http://bugs.winehq.org/show_bug.cgi?id=55151
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Regression SHA1| |bc4f1d60680bf1c8c69a4eb9357 | |15b6cf5c04ba5 Status|NEW |RESOLVED
--- Comment #6 from Eric Pouech eric.pouech@gmail.com --- they was two different issues: 1) native cmd.exe allows modifying .cmd/.bat (and erase/recreate) while executing a command file; this has been fixed with something along what's described in comment #2 2) the script in #1 was causing infinite queueing of file deletion ops (to be applied after all handles are closed) in wine server
fixing 1) let 2) no longer happens from running example from #1
anyway, the sequence in 2) could happen even with win32 APIs. It has been fixed in bc4f1d60680bf1c8c69a4eb935715b6cf5c04ba5.
closing (with SHA1 of fix of 2) as it has been the latest).
http://bugs.winehq.org/show_bug.cgi?id=55151
--- Comment #7 from axis6404@proton.me --- Thank you for your help. I'm very happy that the .bat file is working correctly :)
http://bugs.winehq.org/show_bug.cgi?id=55151
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.16.