[Bug 57008] New: _fdopen(0) does not return stdin after it was closed
https://bugs.winehq.org/show_bug.cgi?id=57008 Bug ID: 57008 Summary: _fdopen(0) does not return stdin after it was closed Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: pipcet(a)protonmail.com Distribution: --- GNU Emacs contains the following code (abbreviated slightly): HANDLE stdin_save = INVALID_HANDLE_VALUE; DuplicateHandle (parent, GetStdHandle (STD_INPUT_HANDLE), parent, &stdin_save, 0, FALSE, DUPLICATE_SAME_ACCESS); fclose (stdin); if (stdin_save != INVALID_HANDLE_VALUE) _open_osfhandle ((intptr_t) stdin_save, O_TEXT); else _open ("nul", O_TEXT | O_NOINHERIT | O_RDONLY); _fdopen (0, "r"); The idea is that the last call to _fdopen will return stdin, so we can continue using stdin after this code runs, but its HANDLE will have become non-inheritable. This doesn't work on wine, which allocates a new FILE * in msvcrt_alloc_fp: for (i = 3; i < MSVCRT_max_streams; i++) { file = msvcrt_get_file(i); if (!file) return NULL; if (file->_flag == 0) { ... return file; } } The loop starts at index 3, not 0, so the stdin/stdout/stderr handles are never reused. Of course, what Emacs does is highly dodgy and not documented to work; apparently, it doesn't work with UCRT on native Windows either. However, there is interest in keeping Emacs usable on very old Windows systems, so it's possible that changing the Emacs code would break things subtly. Is there any possibility or interest in changing wine so it emulates MSVCRT behavior for this application? Changing "i = 3" to "i = 0" would probably suffice... -- 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=57008 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- Could you provide a minimal sample as a 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=57008 pipcet(a)protonmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pipcet(a)protonmail.com --- Comment #2 from pipcet(a)protonmail.com --- Created attachment 76847 --> https://bugs.winehq.org/attachment.cgi?id=76847 Test case I can't verify this on a Windows system right now, but under wine, the output is something like: 00006FFFFFB04220 0 = 0 00006FFFFFB04220 = 00006FFFFFB042B0 Under Windows MSVCRT, the last equality should be true. Under UCRT, it's apparently false, as UCRT appears to behave like wine (reuse file handles starting at fd=3, but never reuse stdin, stdout, or stderr). I'd appreciate if someone could attach the relevant logs :-) -- 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=57008 --- Comment #3 from pipcet(a)protonmail.com --- I've confirmed that with the mingw32-compiled stdin.c: 74df7600 0 = 0 74df7600 = 74df7600 using a GitHub Action running on windows-latest: https://github.com/pipcet/wine57008/actions/runs/10134269756/job/28020306612 -- 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=57008 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Fabian Maurer <dark.shadow4(a)web.de> --- Thanks, confirming against Win7 as well. -- 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=57008 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |f5e4c5cc01f9a8eb170b7d24c2b | |a8402a4e07c83 --- Comment #5 from Piotr Caban <piotr.caban(a)gmail.com> --- The attached test case is fixed by f5e4c5cc01f9a8eb170b7d24c2ba8402a4e07c83. -- 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=57008 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 9.15. -- 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