DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F8263851C22
To: <cygwin@cygwin.com>
References: <008001d62513$42ec3130$c8c49390$@gmail.com>
 <20200508101015.GI3947@calimero.vinschen.de>
In-Reply-To: <20200508101015.GI3947@calimero.vinschen.de>
Subject: Sv: ECONNABORTED and ECONNRESET on TCP socket using recv()
Date: Fri, 15 May 2020 11:04:09 +0200
Message-ID: <009f01d62a97$cba980c0$62fc8240$@gmail.com>
MIME-Version: 1.0
Thread-Index: AQIaP9y2mMe8hVyfmpYJqEWtiRucOQNQ6vWTqAYej6A=
Content-Language: en-gb
From: Kristian Ivarsson via Cygwin <cygwin@cygwin.com>
Reply-To: sten.kristian.ivarsson@gmail.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces@cygwin.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] 

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple