[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-server-cvs
Subject:    [Server-cvs] protocol/rtsp crtspbase.cpp, 1.20.2.25.2.13,
From:       dcollins () helixcommunity ! org
Date:       2009-02-25 20:59:51
Message-ID: 200902252104.n1PL4EvS028590 () mailer ! progressive-comp ! com
[Download RAW message or body]

Update of /cvsroot/server/protocol/rtsp
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv14469/server/protocol/rtsp

Modified Files:
      Tag: SERVER_12_1
	crtspbase.cpp 
Log Message:
Synopsis
========
Fix for PR 235921: UPTIME: SSPL-triggered memory leak of ClientSession-related objects

Branches: SERVER_12_1, HEAD
Reviewer: Jamie


Description
===========

Problem:
~~~~~~~~
The uptime automation switching scripts use the same range of GUIDs
(1-200) for both FCS and SSPL requests.  Occasionally there would be
an overlap between an SSPL switch request and an actual connected FCS
client using the same GUID.

Both SSPL and FCS were using the same proc->pc->session_map object.
The GUIDs they are using for the map key are however are not related.

As a result, entries were being made to the map for FCS and removed by
SSPL since they just randomly happened to use the same GUID.  This was
resulting in a leak of ClientSession objects, and other related objects.

Solution:
~~~~~~~~~
The solution (as you have probably already guessed :) is to have separate
map instances for FCS and SSPL.  They continue to use the same map
implementation, CHXThreadSafeMap.

Note: there still exists a much less frequent leak of these objects,
caused by an unrelated CHXThreadSafeMap-related bug.  (It happened three
times in 20 hours, as opposed to thousands of times before the above fix).
I will enter a separate PR for this.  One of the problems is a lack of
proper error checking.  Things are just added and removed from the maps
without checking whether something is already there or if it failed.


Files Affected
==============

server-restricted/protocol/http-ctrl/fcsgethandler.cpp
server-restricted/protocol/http-ctrl/ssplgethandler.cpp
server/engine/core/core_proc.cpp
server/engine/core/proc_container.cpp
server/engine/core/pub/proc_container.h
server/engine/session/clientsession.cpp
server/protocol/rtsp/crtspbase.cpp


Testing Performed
=================

Unit Tests:
- None

Integration Tests:
- Ran an overnight uptime with instrumentation.  This showed that the
  above-mentioned leak was fixed.

Leak Tests:
- Printfs demonstrated that the objects that were leaking before were
  no longer leaking.

Performance Tests:
- None

Platforms Tested: sunos-5.10-sparc-server
Build verified: sunos-5.10-sparc-server, win2k3-i386-vc7


QA Hints
========
- Regress the PR with new uptimes.



Index: crtspbase.cpp
===================================================================
RCS file: /cvsroot/server/protocol/rtsp/crtspbase.cpp,v
retrieving revision 1.20.2.25.2.13
retrieving revision 1.20.2.25.2.14
diff -u -d -r1.20.2.25.2.13 -r1.20.2.25.2.14
--- crtspbase.cpp	23 Feb 2009 20:16:56 -0000	1.20.2.25.2.13
+++ crtspbase.cpp	25 Feb 2009 20:59:49 -0000	1.20.2.25.2.14
@@ -8015,7 +8015,7 @@
         CHXString sGuid;
         IUnknown *pSessionControlObj = NULL;
         fcsConfig.RetrieveQueryParams(pUrl, NULL, &sGuid, NULL, NULL, NULL); 
-        m_proc->pc->session_map->find((const char *)sGuid, pSessionControlObj);
+        m_proc->pc->fcs_session_map->find((const char *)sGuid, pSessionControlObj);
         if(pSessionControlObj)
         {
             /* control Id already in use, so quit*/


_______________________________________________
Server-cvs mailing list
Server-cvs@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/server-cvs
[prev in list] [next in list] [prev in thread] [next in thread]