Re: Winsock closesocket() problem

[Corinna Vinschen <vinschen at redhat dot com>]

On Thu, Mar 06, 2003 at 10:40:47AM -0500, Jason Tishler wrote:
> On Thu, Mar 06, 2003 at 10:01:30AM -0500, Pierre A. Humblet wrote:
> > Jason Tishler wrote:
> > > Note that the problem follows the second close().  If I switch the
> > > order of the close() calls, then dup()-ed socket closes without any
> > > errors.  Hence, I don't believe that this problem is directly
> > > related to dup().
> > 
> > and then closing the original socket fails. Correct?
> 
> Yes, with the above change I get the following:
> 
>     $ sc9
>     close(fd) failed with 108
> 
> > last time we talked you indicated that the socket was in fact not
> > closed.
> 
> Sorry, I meant to get back to you and inform you that the above
> conclusion was wrong.
> 
> I misinterpreted from where the following Sysinternals' Process
> Explorer output came:
> 
>     0x10   File             0x001F01FF   \Device\Afd\Endpoint
>     0x110  File             0x001F01FF   \Device\Afd\Endpoint
> 
> The first line above is created *before* socket() is called.  The second
> one is created by socket() and deleted by the first close().  So, if my
> current interpretation is correct, then the socket is indeed being close
> albeit possibly too soon.
> 
> > Do you know think it is closed but Windows errs in reporting an error?
> 
> Yes, I think the socket is closed, but I don't understand why Windows
> reports a WSAENOTSOCK error.

I debugged this situation and I have good news for you:  You are not
alone.  I also have not the faintest idea what goes on :-(

I even tried reverting the uid/gid to SYSTEM but it still fails in the
same way.

And as you wrote, running under gdb or strace, everything's fine.  So,
to avoid a timing issue, I added a sleep() between the two close calls
and... nothing changed.

Removing the setgroups() call doesn't change anything.  But removing
one of setuid/setgid let the error disappear.

Hmmm,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin at cygwin dot com
Red Hat, Inc.