https://bugs.winehq.org/show_bug.cgi?id=37669
--- Comment #23 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #21)
Please give it a try. Works well with your attached tests for me.
Thank you Sebastian, new patch set works quite well, and indeed my test no longer shows a read error. Unfortunately the real application I have here still dies on an exception on signal thread after 15-20 minutes of work under pretty heavy load. I haven't figured out yet the reason, still investigating.
Finally found time to investigate the problem. Sebastian's patch works perfectly for recv/WSARecv/recvfrom/WSARecvFrom, now the problem has appeared in another place: asynchronous callback of AcceptEx - WS2_async_accept. This callback writes into the application provided buffer all over the place, and I personally don't see a reasonable way to fix it without allowing SEH on a signal stack. A usual approach used in Wine code of checking the application provided buffer with IsBadWritePtr at the start of WS2_AcceptEx just postpones the crash and creates another race between the GC thread and winsock code.
While investigating the problem with AcceptEx I have found another place where write watches cause a race and a lead to a failure to read normal disk file in a .net application I'm working on: it's ReadFile. While fixing ReadFile (actually NtReadFile) was trivial (I'll attach a patch) since it's not called on a signal stack, this shows that potentially any place of Wine code is vulnerable to the races caused by write watches.
Just for the background: this .net application is a very simple client/server written using .net's System.Runtime.Remoting class.