You are right about the "removeSocketDescription" my explication was not good, forget about this. I should not have waste time trying to find an explanation because I don't have a clear view why this is happening. However this is what I have found so far, if this can help anybody track this down.
So it first start with a readSocket failure on socket X, this trigs a
deletion if SocketDescriptor, this I am sure.
Now I do see that just after that background handling is turned on again on
the socket X, just when a new TCP client connects using socket Y and is
asking for the stream. Right after that boom... bad file descriptor error.
This new background handling comes from a call in
RTPInterface::startNetworkReading, this is what I found by logging all
access to all TCP sockets in the code.
It looks like something is not cleaned up properly when the readSocket
failure occurs. I will try to create a test that reproduces the problem
easily because so far this is very hard to repro, it is a question of
having the right timing. Hope this help.
Serge
Miranda Technologies
From: Ross Finlayson <finlay...@live555.com>
To: LIVE555 Streaming Media - development & use
<live-de...@ns.live555.com>,
Date: 2013-06-18 16:04
Subject: Re: [Live-devel] windows winsock error 10038
Sent by: live-devel-boun...@ns.live555.com
The problem I found is in RTPInterface.cpp file
-> SocketDescriptor::tcpReadHandler1 line 422
If readSocket fails (-1) it triggers a deletion of the
SocketDescriptor object
Correct.
However this is leaving a dangling pointer in the HashTable in
RTPInterface (lookupSocketDescriptor)
Incorrect - because the "SocketDescriptor" destructor calls
"removeSocketDescription()", which will remove the "SocketDescriptor"
object from the hash table.
(Note that the "SocketDescriptor" destructor also calls
"turnOffBackgroundReadHandling()" on the socket, so that this socket will
no longer get used in the event loop's "select()".)
As I noted earlier, the "bad file descriptor" error (or other socket error)
in "select()" is caused by a socket getting closed somewhere without
"turnOffBackgroundReadHandling()" also being called for the socket. It's
conceivable that there is a bug in the LIVE555 code somewhere that is
causing this to happen - in which case I invite people to try to track it
down. However, what you described above is not it.
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
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
<<inline: graycol.gif>>
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
