[Live-devel] Two possible problems in RTSPServer class

[Ross Finlayson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120422/f8dc64b0/attachment.html>