ws2_32: WSACleanup cleans up open sockets (OSX only)

[Matt Durgavich]

Thanks for all the great input. I'm an experienced developer but a newbie
at wine dev, so the input is greatly appreciated.

I'll take a stab at iterating on Bruno's last patch to leverage the
server's handles.
-Matt

On Sun, Aug 2, 2015 at 11:13 AM, Bruno Jesus <00cpxxx at gmail.com> wrote:

> 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> 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>
>> 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/32c444b2/attachment.html>