https://bugs.winehq.org/show_bug.cgi?id=52474
Bug ID: 52474 Summary: ws2_32:sock fails intermittently - 'Test failed: expected timeout' Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs@winehq.org Reporter: jinoh.kang.kr@gmail.com Distribution: ---
The test_connect_events() function contains the following checks, where the check (2) fails intermittently:
1. check_events(ctx, FD_CONNECT, FD_WRITE, 200); 2. check_events(ctx, 0, 0, 0);
A hypothesis for the cause of the test failure is that the WSAEnumNetworkEvents() call inside the check (1) races with the server setting the event.
Note that WSAEnumNetworkEvents performs the following steps:
a. It calls ResetEvent on the given event. b. It issues IOCTL_AFD_GET_EVENTS command on the socket to retrieve the events so far.
It's possible that the event may be set by the server between (a) and (b), which lingers until the next call to WSAEnumNetworkEvents(). This explains why the event wait in check (2) is satisfied immediately but subsequent tests report no events.
https://bugs.winehq.org/show_bug.cgi?id=52474
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase CC| |fgouget@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=52474
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #1 from François Gouget fgouget@codeweavers.com --- One can identify this issue by looking for the following failure in the report:
sock.c:6261: Test failed: expected timeout
See https://test.winehq.org/data/patterns.html#ws2_32:sock
Also note that the same failure also happens in test_close_events(). See the timeout case of bug 54073.
https://bugs.winehq.org/show_bug.cgi?id=52474
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|ws2_32:sock fails |ws2_32:sock - |intermittently - 'Test |test_connect() fails |failed: expected timeout' |intermittently with 'Test | |failed: expected timeout' CC| |z.figura12@gmail.com
--- Comment #2 from Zeb Figura z.figura12@gmail.com --- So I find the explanation plausible enough to just assume it's correct.
The documentation [1] has this to say:
"The socket's internal record of network events is copied to the structure referenced by lpNetworkEvents, whereafter the internal network events record is cleared. If hEventObject is non-null, the indicated event object is also reset. The Windows Sockets provider guarantees that the operations of copying the network event record, clearing it, and resetting any associated event object are atomic, such that the next occurrence of a nominated network event will cause the event object to become set."
We can't "just" make this atomic, but on the other hand, we're building on top of an actual undocumented AFD API. I played with this a bit and discovered, to my chagrin, that IOCTL_AFD_GET_EVENTS does support resetting an event. Trouble is, it's done like this:
NtDeviceIoControlFile((HANDLE)socket, NULL, NULL, NULL, &io, IOCTL_AFD_GET_EVENTS, event, 0, ¶ms, sizeof(params));
i.e. with the event passed *as* a pointer.
This is not impossible to support, but the translation will have to be done in ntdll.
[1] https://learn.microsoft.com/en-us/windows/win32/api/ws2spi/nc-ws2spi-lpwspen...
https://bugs.winehq.org/show_bug.cgi?id=52474
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |01afb21bf2b3a9c6b03847b03a1 | |ac4a572ed49a3
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- Should hopefully be fixed by https://source.winehq.org/git/wine.git/commitdiff/01afb21bf2b3a9c6b03847b03a1ac4a572ed49a3. Since it's rare in the first place, let's assume fixed, and reopen if we see this happening again.
https://bugs.winehq.org/show_bug.cgi?id=52474
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.14.