http://bugs.winehq.org/show_bug.cgi?id=58122
Bug ID: 58122 Summary: WSAENOTSOCK error when calling winsock.Send() on duplicated socket Product: Wine-staging Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: digitman63@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Process A creates a listening socket, accepts an incoming connection, and obtains a socket handle hSock.
Process A spawns Process B with the InheritHandles flag, passing its own ProcessID and the socket handle hSock as command-line arguments.
Process B calls OpenProcess() to get a handle hSrcProcess for the given ProcessID, then duplicates hSock into hDupSock using DuplicateHandle(hSrcProcess, hSock, GetCurrentProcess(), &hDupSock, ...); Process B successfully receives data from the duplicated socket using winsock.recv(hDupSock, ...).
Process B attempts to send data via winsock.send(hDupSock, ...), but the call fails with WSAENOTSOCK (10038) ("Socket operation on non-socket").
Process B then tries sending the same data using kernel32.WriteFile(hDupSock, ...), and this operation succeeds.
Why does send() fail while WriteFile() works on the same duplicated handle?
http://bugs.winehq.org/show_bug.cgi?id=58122
--- Comment #1 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 78383 --> http://bugs.winehq.org/attachment.cgi?id=78383 patch
Does the attached patch help?
http://bugs.winehq.org/show_bug.cgi?id=58122
--- Comment #2 from digitman digitman63@gmail.com --- The attached patch refers to a UDP socket, in my case it is a TCP socket
http://bugs.winehq.org/show_bug.cgi?id=58122
--- Comment #3 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to digitman from comment #2)
The attached patch refers to a UDP socket, in my case it is a TCP socket
Attached patch is not specific to any socket type. Did you test it?
http://bugs.winehq.org/show_bug.cgi?id=58122
--- Comment #4 from digitman digitman63@gmail.com --- No, i didn't..
Yes, it looks like this patch really does fix the problem, which makes it even more unclear why it hasn't been applied to Staging yet.
http://bugs.winehq.org/show_bug.cgi?id=58122
--- Comment #5 from digitman digitman63@gmail.com --- My scenario is typical for the work of the Embarcadero Rad Studio PAServer remote debugger - in a remote debugging session of a Win32 application, it launches two RmtDbgXXX.exe processes sequentially, the first process creates a listening socket, accepts an incoming TCP connection and passes the TCP socket to the second process to implement exchange with PAClient as part of the client part of the distributed debugger.
Due to this issue, remote debugging sessions are fundamentally impossible in any version of Wine.
http://bugs.winehq.org/show_bug.cgi?id=58122
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords| |patch
--- Comment #6 from Dmitry Timoshkov dmitry@baikal.ru --- I sent a patch https://gitlab.winehq.org/wine/wine/-/merge_requests/7845 however it was rejected.
http://bugs.winehq.org/show_bug.cgi?id=58122
--- Comment #7 from digitman digitman63@gmail.com --- (In reply to Dmitry Timoshkov from comment #6)
I sent a patch https://gitlab.winehq.org/wine/wine/-/merge_requests/7845 however it was rejected.
imho the refusal was logical - the patch looks like a crutch
http://bugs.winehq.org/show_bug.cgi?id=58122
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |a08d6d8be08b9408bd61d5a5c0f | |38b4c65c20ac0 Status|NEW |RESOLVED Keywords|patch |
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru --- This should be fixed by a08d6d8be08b9408bd61d5a5c0f38b4c65c20ac0.