Sv: ECONNABORTED and ECONNRESET on TCP socket using recv()

[<sten.kristian.ivarsson@gmail.com>]

> > Hi all
> >
> > Have anyone experienced getting ECONNABORTED and ECONNRESET on local
> > TCP socket when using recv() ?
> >
> >
> > We have a fairly complex application where it, amongst others, spawns
> > child processes (using posix_spawnp)
> >
> > This is a simplified scenario
> >
> > - parent performs socket() + bind() + listen() to localhost
> > - parent spawns a client-child process
> >   - client-child is doing socket() + connect() to localhost
> >   - client-child is doing send()
> >   - client-child is doing recv() and getting ECONNRESET
> >
> > - parent performs accept()
> > - parent spawns a server-child process
> >   - server-child is doing recv() and getting ECONNABORTED
> >
> >
> > According to strace, both of these errors originates from
> > fhandler_socket_inet::recv_internal() (in my version it says line
> > 1221)
> 
> The errors are generated by the called Windows function WSARecvFrom.
> We'd need a reproducible testcase for this to allow debugging.

The application is quite complex but I guess it won't count as a test-case
and we still fail to reproduce this in a simple manner


Looking at strace along with winsock-trace revealed a few mysterious though.
According to the strace there's a fork for every posix_spawnp, i.e. it seems
like two processes are created (the forked later exits) but they are somehow
tied to the same cygwin-pid. The weird thing is that one of the forked
"ghost-processes" gets a winsock-abort-event, so my take on this is that the
dup(lications) of socket-descriptors kind of transforms the ownership to the
wrong process or perhaps there's some premature release or such. The
"ghost-process" getting the winsock-abort-event are of a type that should
"inherit" the accept-socket and is called "client-child" in the description
above


The problems doesn't occur in the simplified test-case but if someone is
interested I can give guidance to help building/testing the more complex
test-cases


Does anyone have a clue of where we could find some more clues about this
and/or if something obvious come to someone's mind of how to proceed ?


There are some comments that might be related to this in the implementation
of fhandler_socket_inet::recv_internal() though the comments does not really
describe our scenario


Best regards,
Kristian




> > Maybe there's some defect in our application (there's a lot of other
> > fuzz going on as well), but it works in several Linux-implementations
> > but this error is deterministically occurring using CYGWIN
> >
> >
> > I've searched mail archives but I cannot really find any explanation
> > or cause
> >
> > Does anyone have any knowledge about this ?

[snip]