> > 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
