>> I have now installed a new version (2017.01.26) of the “LIVE555 Streaming
>> Media” code that incorporates your patch (mostly).
> Thanks a lot Ross, this is great!
>
> I've found one more more similar issue, the new one is triggered by the
> following sequence:
> - Connection to back-end server is torn down
> - The torn down connection triggers a read error which causes the socket to
> be closed
> - If a client to the proxy at this point issues PLAY, the closed socket will
> still be referenced, causing this error:
> BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor
This error is always caused by a socket being closed without
disableBackgroundHandling()
or, equivalently
turnOffBackgroundReadHandling()
having been first called on it. In other words, whenever a socket is being
read from asynchronously (i.e., from the event loop),
"disableBackgroundHandling()” or "turnOffBackgroundReadHandling()” MUST be
called on the socket before it gets closed.
So, the questions are:
1/ Which socket is being closed, and where, and
2/ Why was "disableBackgroundHandling()” or
"turnOffBackgroundReadHandling()” not called on it beforehand?
There several places in the code where "disableBackgroundHandling()” or
"turnOffBackgroundReadHandling()” are currently called, prior to a socket
being closed; in particular:
- For a RTP/RTCP-over-RTSP socket, “turnOffBackgroundReadHandling()” is
called in the “SocketDescriptor” destructor (“RTPInterface.cpp”).
- For a “RTSPClient", "disableBackgroundHandling()” is called in
“resetTCPSockets()” (“RTPInterface.cpp”).
- For a "RTSPServer::RTSPClientConnection”,
“disableBackgroundHandling()” is called when the client connection is closed
(“RTSPServer.cpp”, line 578)
So, which one did we miss?
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
