> 1. I have seen possible ServerMediaSession object leak in > RTSPServer::RTSPClientSession::handleCmd_SETUP method. > This method changes client session object member variable > fOurServerMediaSession (pointer to ServerMediaSession) and calls > fOurServerMediaSession->incrementReferenceCount() if this > ServerMediaSession is really changed. But this method does not call > decrementReferenceCount() on previously stored ServerMediaSession (if > any). So if an RTSP client will send two SETUP commands referring > different streams then ServerMediaSession object of stream of first > SETUP command will have excess reference counter increment that will > prevent this ServerMediaSession object from being deleted. Maybe there > are no such RTSP client but I think any protection against harmful > behaviour of other software is welcome.
Yes, there exist unusual situations in which the reference count might get too high, but fixing this is not a high priority, because in the most common situations, the reference count will get set correctly. (Also, it is relatively unusual for "removeServerMediaSession()" to be called.) > 2. Also I have seen possible ServerMediaSession object relations bug > in RTSPServer::addServerMediaSession/RTSPServer::removeServerMediaSession > methods. > Method addServerMediaSession adds a ServerMediaSession object to > hashmap fServerMediaSessions and call removeServerMediaSession on > ServerMediaSession object previously set in the hashmap (if both > objects have same stream name). Method removeServerMediaSession > removes from the hashmap new ServerMediaSession object just added by > addServerMediaSession. Yes, this is a bug. It will get fixed in a future release. (Perhaps then I'll address the first issue also :-) Thanks for reporting this. 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
