[SFtrack] Commented: (XECS-59) Overnight LoadTest failure - sipXvxml memory hog
[ http://track.sipfoundry.org/browse/XECS-59?page=comments#action_20726 ]
Andy Spitzer commented on XECS-59:
----------------------------------
My gut feeling is that the leak is caused by the "SBinetLogFunc apiTrace()"
objects they use. Many of them seem to be passing pointers to VXIchar, which
is wide, but using the "%s" format for them. Eventually that makes is way down
to vswprintf(), which on Linux seems to leak if the arguments don't match the
formats.
I started trying to find all the places %s was used where %ls was needed, and
got discouraged.
--Woof!
> Overnight LoadTest failure - sipXvxml memory hog
> ------------------------------------------------
>
> Key: XECS-59
> URL: http://track.sipfoundry.org/browse/XECS-59
> Project: sipXecs
> Issue Type: Bug
> Affects Versions: 3.7
> Environment: [sipx@markg-sipx2 sipxpbx]$ uname -a
> Linux markg-sipx2 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 i686
> i686 i386 GNU/Linux
> [sipx@markg-sipx2 bin]$ ~/sipxecs/out/main/bin/sipx-config --version
> sipX version information:
> sipxportlib 3.7.0-010003 2007-04-15T14:20:51 markg-sipx2
> sipxtacklib 3.7.0-010003 2007-04-15T14:23:22 markg-sipx2
> sipxmedialib 3.7.0-010003 2007-04-15T14:26:05 markg-sipx2
> sipxcalllib 3.7.0-010003 2007-04-15T14:29:46 markg-sipx2
> sipxcommserverlib 3.7.0-010003 2007-04-15T14:35:02 markg-sipx2
> sipxregistry 3.7.0-010003 2007-04-15T14:38:49 markg-sipx2
> sipxpublisher 3.7.0-010003 2007-04-15T14:38:38 markg-sipx2
> sipxproxy 3.7.0-010003.sipx 2007-04-15T14:37:56 markg-sipx2
> sipxconfig 3.7.6-010003 2007-04-15T14:46:39 markg-sipx2
> sipxvxml 3.7.0-010003 2007-04-15T14:40:12 markg-sipx2
> sipxpbx 3.7.0-010003 2007-04-15T14:48:34 markg-sipx2
> XECS-47 fix is applied ontop.
> Reporter: Mark Gertsvolf
> Assigned To: Andy Spitzer
> Fix For: 3.8
>
> Attachments: leak.4.patch, mem.leak.1.patch, mem.leak.3.patch
>
>
> A rather heavy test consisting of 6 SIPP scripts has stalled 100% overnight.
> sipXvxml process is 1.5G in size. All new requests receive 408 Request timeout
> I forgot to turn on the debug logs, but even with NOTICE level the logs are
> 95M.
> The test consisted of the following:
> 1. register-unregister test. 20 simultaneous registrations from 20 different
> users followed by a deregistration after 30 seconds followed by a pause of 32
> seconds.
> 2. MWI subscribe-unsibscribe test. 20 simultaneous MWI subscription dialogs
> setup for 30 seconds followed by dialog termination and a pause of 40 seconds.
> 3. Simple call test. User registered from EyeBeam with AutoAnswer function
> turned on. The test makes a single call, EyeBeam answers, the test waits 2
> seconds, plays a 7-second pre-recorded message and disconnects, then waits 2
> more seconds.
> 4. VM call test. 20 simultaneous calls to VM. 14 seconds after VM answers the
> test disconnects.
> 5. VM message deposit. 20 simultaneous calls to an unregistered user, calls
> answered by VM and a 7-second pre-recorded message is deposited to the VM box.
> 6. XECS-47 test. This test sends 20 simultaneous requests with unsupported
> extention in Proxy-Require header, expects to receive 420 response then waits
> 5 seconds.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://track.sipfoundry.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
