well, that looks better, doesn't it? ==27075== LEAK SUMMARY: ==27075== definitely lost: 0 bytes in 0 blocks. ==27075== possibly lost: 2,016 bytes in 25 blocks. ==27075== still reachable: 85,200 bytes in 150 blocks.
btw your MBs uncompressed log are giving my thunderbird a hard time... ;) Stefan o Laurent Schweizer [06/03/08 18:28]: > New test, with updated version. > > Laurent > > -----Original Message----- > From: Raphael Coeffic [mailto:[EMAIL PROTECTED] > Sent: mardi 3 juin 2008 12:42 > To: Laurent Schweizer > Cc: Stefan Sayer; [EMAIL PROTECTED] > Subject: Re: [Semsdev] 2 problems with sems > > Hi Laurent, > > are you sure that you updated your code (SVN:trunk) up to version 1001? > In the logs, i cannot find the new timer L, which is the major piece of > the fix. Could please check if you can find this timer in your code? > > grep -r STIMER_L * > > shall return something in the sipctrl plug-in. > > -Raphael. > > Laurent Schweizer wrote: >> I do the test with SW_prepaid_sip application, not with my > application. >> I will do the same test with my application. >> >> Laurent >> >> >> -----Original Message----- >> From: Stefan Sayer [mailto:[EMAIL PROTECTED] >> Sent: mardi 3 juin 2008 11:55 >> To: Laurent Schweizer >> Cc: [EMAIL PROTECTED]; Raphael Coeffic >> Subject: Re: [Semsdev] 2 problems with sems >> >> >> >> o Laurent Schweizer [06/03/08 10:22]: >> >>> Hello, >>> >>> Attached log of my last test with last version. >>> >>> I wait after the last call before killing sems . >>> >>> Laurent >>> >>> >> something must be wrong with your application logic: you still have 74 > >> sessions running. check that you end all sessions with setStopped(). >> >> Stefan >> >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Sayer >>> Sent: lundi 2 juin 2008 13:31 >>> To: Raphael Coeffic >>> Cc: [EMAIL PROTECTED] >>> Subject: Re: [Semsdev] 2 problems with sems >>> >>> >>> >>> o Raphael Coeffic [06/02/08 12:26]: >>> >>>>>> It looks like you have a lot (405) of thrashed sessions still in >>>>>> >>> memory. >>> >>>>> where do you see them? >>>>> >>>>> >>>> In the memory traces. >>>> >>> ah ;) >>> >>> but how is the transactions on sip stack level linked to the session >>> objects other than the transaction id? i mean, how will freeing the >>> session affect sip stack's memory? >>> >>> i see the count 405 only in loss record 43, 47 and 106, and they are >>> >> all >> >>> sip transaction related and not on dialog/session level. >>> >>> Stefan >>> >>> >>>> -Raphael. >>>> >> > -- Stefan Sayer VoIP Services [EMAIL PROTECTED] www.iptego.com iptego GmbH Am Borsigturm 40 13507 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
