[Bug 59126] New: NtFsControlFile(FSCTL_PIPE_WAIT) fails to detect infinite timeout
http://bugs.winehq.org/show_bug.cgi?id=59126 Bug ID: 59126 Summary: NtFsControlFile(FSCTL_PIPE_WAIT) fails to detect infinite timeout Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: services@mlugg.co.uk Distribution: --- When calling NtFsControlFile with the FSCTL_PIPE_WAIT control code, the Timeout field in the FILE_PIPE_WAIT_FOR_BUFFER structure is not interpreted correctly. An infinite timeout (equivalent to NMPWAIT_WAIT_FOREVER in kernel32's WaitNamedPipeW) is, on Windows proper, specified by the minimum signed 64-bit integer value, i.e. 0x8000_0000_0000_0000. This behavior is not documented, but can be observed by tracing the ntdll calls triggered by WaitNamedPipeW; and ReactOS also agrees with this value. However, Wine instead represents an infinite timeout using the value 0x7FFF_FFFF_FFFF_FFFF (the *maximum* signed 64-bit integer, aka TIMEOUT_INFINITE). This logic is internally consistent: the WaitNamedPipeW implementation converts NMPWAIT_WAIT_FOREVER to that value, and the server detects it in async_set_timeout (called from named_pipe_device_ioctl in server/named_pipe.c). However, it causes direct usage of this ntdll API to incorrectly return STATUS_IO_TIMEOUT when the correct "infinite timeout" value is passed. I suspect the logic in named_pipe_device_ioctl should be modified to detect the special value 0x8000_0000_0000_0000 and avoid setting a timeout in that case, and that WaitNamedPipeW should be modified to translate NMPWAIT_WAIT_FOREVER to that value rather than 0x7FFF_FFFF_FFFF_FFFF. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59126 --- Comment #1 from Alexandre Julliard <julliard@winehq.org> --- Is there any app that depends on this? Tracing the internal calls of Windows is not allowed, and not something we want to replicate unless necessary. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59126 --- Comment #4 from Matthew Lugg <services@mlugg.co.uk> --- Created attachment 79987 --> http://bugs.winehq.org/attachment.cgi?id=79987 Test case Here's a test case which sometimes fails on master. The expected behavior (which Windows exhibits) is to print "begin wait", then block indefinitely. However, some builds of Wine will print "begin wait" immediately followed by "wait timed out" and exit. (Because this depends on UB in Wine, the bug may or may not be reproducible for you. A UBSan-enabled Wine build should complain, though I've not tested that and have no idea whether Wine is generally UBSan-clean.) I have been able to confirm that on a system where this reproduction triggers the bug, applying the patch I suggested above does fix it (i.e. it makes this reproduction work as expected). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59126 Matthew Lugg <services@mlugg.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |wineserver -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59126 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, 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.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla