> I know your stance on memory leaks
No you don't :-)
> In the SocketDescriptor destructor, the HashTable::Iterator* “iter” is never
> deleted.
Yes - that was an oversight on my part. It will be fixed in the next release
of the software.
> In SocketDescriptor::deregisterRTPInterface, the fDeleteMyselfNext member is
> set to “true”, but (for me at least), the tcpReadHandler function is never
> called again, and so the SocketDescriptor deletion never happens. I believe
> this was changed from “delete this;” in version 2013.04.29 or 2013.04.30 to
> avoid crashing if the tcpReadHandler is about to execute just after the
> socket descriptor is deleted.
>
> A fix that works here and does not result in a memory leak is to change the
> fDeleteMyselfNext back to “delete this;”
No, I can't do that, because if that code happens to be called while we're
inside "tcpReadHandler1()" - i.e., while we're inside this loop:
while (!socketDescriptor->fDeleteMyselfNext &&
socketDescriptor->tcpReadHandler1(mask) && --count > 0) {}
then the code will crash the next time it tries to dereference
"socketDescriptor" to test the loop condition.
However, do you raise a valid point: If
"SocketDescriptor::deregisterRTPInterface()" happens to be called when we're
*not* inside "tcpReadHandler1(), then (with the current code) the
"SocketDescriptor" object won't get deleted. I'll add a fix for this
(different from the one that you suggested) to the next release of the code.
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
