Mail Archives: cygwin-developers/2003/03/07/08:14:49
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.
- Raw text -