[Bug 57804] New: cmd: CALL instruction freezes
https://bugs.winehq.org/show_bug.cgi?id=57804 Bug ID: 57804 Summary: cmd: CALL instruction freezes Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: Dominik-Home(a)gmx.de Distribution: --- Executing the 'CALL'-instruction on a *.bat file may causes freezes when using e.g. '@echo off' in the called script. ```console $ wine --version wine-10.0 (Staging) ``` I inserted two minimal reproducers below that are used in the following examples. Note that I marked the output of the scripts as comment with the REM command as well as my own descriptions. ```cmd C:\>C:\working.bat REM C:\>echo Test REM Test REM Command returns immediately. No issue here C:\>C:\issue.bat REM Test REM Command returns immediately. No issue here C:\>CALL C:\working.bat REM C:\>echo Test REM Test REM Command returns immediately. No issue here C:\>CALL C:\issue.bat REM Test REM ISSUE: Command freezes here and never returns ``` working.bat: ```cmd @echo on echo Test ``` issue.bat: ```cmd @echo off echo Test ``` This issue was encountered while trying out PlanAhead, a tool included in the Xilinx ISE design package. They use multiple batch scripts to configure the environment before starting the GUI application. Because the batch files do not work properly the GUI does not start at all. I.e. the application (PlanAhead) is completely unusable. -- 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=57804 mata <sutupud(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud(a)yahoo.com --- Comment #1 from mata <sutupud(a)yahoo.com> ---
From what I can see it *does* return, it just seems to hang because "echo" stays off.
You can verify that by adding `@echo on` to the end of your batch file. So the issue would be that the terminal prompt is not enabled after calling a batch file (if that's the behaviour on windows, I didn't check...) -- 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=57804 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase -- 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=57804 --- Comment #2 from Dominik-Home(a)gmx.de --- I see and confirm the behaviour you're describing. Windows is showing the prompt after calling issue.bat, i.e. there is still a bug present in Wine but under the changed circumstances it's not that critical anymore. I'm going to change the title and priority of this issue report. For reference, this issue is not the root cause why PlanAhead does not start, I have to investigate a bit further to find the actual issue. -- 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=57804 Dominik-Home(a)gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|cmd: CALL instruction |cmd: '@echo off' gets |freezes |propagated to parent on | |CALL instruction (CALL | |seems to freezes) Severity|major |trivial -- 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=57804 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #3 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 78016 --> https://bugs.winehq.org/attachment.cgi?id=78016 tentative patch this patch shall likely solve the ticket (didn't test it does, but should from the description) -- 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=57804 --- Comment #4 from Eric Pouech <eric.pouech(a)gmail.com> --- did a bit more testings, and situation seems a bit more complex it looks like the restoration of the echo mode only happens when invoking a .bat from the command prompt but not when a .bat calls into another .bat can you confirm that all your testings were done from cmd prompt and calling into a .bat file (which does @echo off) TIA -- 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=57804 --- Comment #5 from Dominik-Home(a)gmx.de --- Thanks for taking a look into this so fast. I haven't had time to compile wine myself and apply this patch yet. But I confirm that all my testing was done from the cmd prompt and not "CALL"ing from one bat-script into another. -- 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=57804 --- Comment #6 from Dominik-Home(a)gmx.de --- Your observation seems to be right, Microsoft documented this behavior:
If used in a batch file, echo on and echo off don't affect the setting at the command prompt. [1]
[1] https://learn.microsoft.com/en-us/windows-server/administration/windows-comm... -- 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=57804 --- Comment #7 from Eric Pouech <eric.pouech(a)gmail.com> --- submitted https://gitlab.winehq.org/wine/wine/-/merge_requests/7301 that shall fix this issue (among other things) -- 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=57804 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2d2c661c6ccf2c1bc93ecfa6088 | |628ccad93cb5d Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Pouech <eric.pouech(a)gmail.com> --- resolved fixed -- 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=57804 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.2. -- 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=57804 --- Comment #10 from Dominik-Home(a)gmx.de --- I'm confirming the fix in 10.2. Thank you very much! -- 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