ws2_32: WSACleanup cleans up open sockets (OSX only)

[Bruno Jesus]

Hi all and sorry, replying from mobile phone so I can't quote things right.

There are a few tests covering this so any patch fixing this problem will
require reviewing the tests too.

I tried to fix this last year, the discussion and patch can be found at
[1]. There is also a real bug related to this problem (18670 and 26031).

1- http://marc.info/?t=138834097400003&r=1&w=2

Best wishes,
Bruno

On Sunday, August 2, 2015, Charles Davis <cdavis5x at gmail.com> wrote:

>
> > On Jul 31, 2015, at 11:31 PM, Ken Thomases <ken at codeweavers.com
> <javascript:;>> wrote:
> >
> > Hi,
> >
> > Thanks for contributing to Wine.  I've commented on the patch in-line
> below:
> >
> > On Jul 31, 2015, at 10:19 PM, Matt Durgavich <mattdurgavich at gmail.com
> <javascript:;>> wrote:
> >
> >> +static void close_open_sockets() {
> >> +#ifdef HAVE_LIBPROC_H
> >> +    int pid = getpid();
> >> +    int bufferSizeNeeded = proc_pidinfo(pid, PROC_PIDLISTFDS, 0, NULL,
> 0);
> >
> > This function isn't documented and the header which declares it says
> it's SPI rather than API and can change at any time.
> Well then, we’re kinda screwed if they do change it, because we already
> use that SPI. (In fact, it’s my fault. ;) In particular, we use it in
> iphlpapi to figure out which process owns a particular socket. (@Matt: this
> also means the check for <libproc.h> you added to configure.ac is
> redundant, because we already check for it. You can delete it.)
> >
> > Also, is this the right approach generally?  This is going to close all
> Unix sockets opened by the process, not just Win32 sockets opened by ws2_32.
> It won’t even (properly) close all (or any, really) of the winsock
> sockets. That’s because winsock sockets in Wine, like on NT, are NT-style
> object handles. That’s really what you have to find and close. Also, even
> if you try to map the FDs back to their corresponding Wine handles, you
> still won’t necessarily get them all, because the wineserver manages FDs
> (including sockets, I believe) on Wine’s behalf; they’re only present in
> the process if Wine bothers to go to the wineserver to get them (cf.
> dlls/ntdll/server.c).
>
> So, I suggest enumerating all the socket handles in the process (e.g. by
> enumerating all handles in this process using toolhelp or psapi, then
> filtering out the ones that aren’t sockets), and closing those. Or, maybe,
> having winsock keep track of sockets that it opens (e.g. returned from
> WSASocket()), then having WSACleanup() close all the ones it knows about.
> The great thing about doing it either of these ways is that it’ll work
> elsewhere, too—not just on Mac OS. The second option I gave might be
> preferable, because e.g. someone could DuplicateHandle() a winsock handle
> into another process, and WSACleanup() might not close it when it runs.
> (Someone should write a test for that.)
> >   Is it safe/proper for WSACleanup to close sockets that it didn't
> open?  Isn't it possible that other parts of Wine could open Unix sockets
> for other reasons?
> It is, and in fact, they do. For one thing, Wine programs use Unix-domain
> (PF_UNIX) sockets to talk to wineserver.
>
> Chip
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150802/22715aa2/attachment.html>