You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(26) |
Jun
(12) |
Jul
(9) |
Aug
(20) |
Sep
(12) |
Oct
(18) |
Nov
(4) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(5) |
Feb
(2) |
Mar
(8) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(23) |
Aug
(5) |
Sep
(2) |
Oct
(7) |
Nov
(5) |
Dec
(12) |
2009 |
Jan
(2) |
Feb
(2) |
Mar
(7) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(12) |
2013 |
Jan
(2) |
Feb
(8) |
Mar
(3) |
Apr
(20) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Charles P W. <cpw...@us...> - 2007-08-08 19:01:49
|
Olivier, I found the latest version to still have a defect in that multiple headers = were still not correctly included. I committed a fix for this. I am also=20 attaching two XML scenarios (a UAC and UAS) that are designed to be used=20 back to back, which verify the proper behavior of the last header using=20 actions. These scenarios can be run as: ./sipp -sf test-uas.xml -m 1 ./sipp -sf test-uac.xml -m 1 -trace=5Flogs localhost If the call was successful, then the UAC returns 0, otherwise it returns=20 97 to the shell. Anatoly, what was the test case that you were using for your patch? I do=20 have a case where a header is empty. In this code if the original message = has: Baz; Baz: value The [last=5FBaz:] keyword returns "Baz:, value". Olivier, I know that you said you were running some regression tests=20 before a 3.0 release. This is an example of how a regression suite would=20 be useful. Maybe, we can create a directory of simple XML scripts that=20 attempt to do some self-verification? Do you already have such a local=20 repository? Charles -- Dr. Charles P. Wright Research Staff Member Network Server Systems Software IBM T.J. Watson Research Center "Boulkroune, Olivier (Non-HP:Atos Origin)" <oli...@hp...>=20 wrote on 08/01/2007 12:34:07 PM: > Oops......I corrected this in the latest revision (293). Sorry about=20 that. >=20 > Thanks and regards, >=20 > Olivier Boulkroune >=20 > -----Message d'origine----- > De : Anatoly Pidruchny [mailto:api...@ne...]=20 > Envoy=E9 : mercredi 1 ao=FBt 2007 17:45 > =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) > Cc : Charles P Wright; sip...@li...;=20 > api...@us... > Objet : Re: [Sipp-devel] [Sipp-commits] SF.net SVN: sipp: [292] > sipp/trunk/call.cpp >=20 > Olivier, >=20 > sorry that I did not verify that earlier. But you did not apply my patch = > correctly! Below is the part from my proposed patch. Please pay=20 > attention to the two modified lines that start from '!' character: >=20 > *************** > *** 1174,1192 **** > // Add "," when several headers are present > if (dest !=3D last=5Fheader) { > /* Remove trailing whitespaces, tabs, and CRs */ > - *(dest--) =3D 0; > while ((dest > last=5Fheader) && > ! ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D = '\t'))) { > ! *(dest--) =3D 0; > } >=20 > dest +=3D sprintf(dest, ","); > - > - /* We only want to append the contents of the header, not its=20 > name for > - * the second value. */ > - if (!content) { > - src +=3D strlen(name); > - } > } > dest +=3D sprintf(dest, "%s", src); > if(ptr) { *ptr =3D '\n'; } > --- 1176,1187 ---- > // Add "," when several headers are present > if (dest !=3D last=5Fheader) { > /* Remove trailing whitespaces, tabs, and CRs */ > while ((dest > last=5Fheader) && > ! ((*(dest-1) =3D=3D ' ') || (*(dest-1) =3D=3D '\r')|| (*(des= t-1) =3D=3D=20 > '\t'))) { > ! *(--dest) =3D 0; > } >=20 > dest +=3D sprintf(dest, ","); > } > dest +=3D sprintf(dest, "%s", src); > if(ptr) { *ptr =3D '\n'; } >=20 >=20 > In revision 284 of call.cpp file you removed the "*(dest--) =3D 0;", but = > you did not modify these two lines. Of course this causes the problem. I = > still think that it is better to do this my way. Instead of: >=20 > /* Remove trailing whitespaces, tabs, and CRs */ > *(dest--) =3D 0; > while ((dest > last=5Fheader) && > ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D '\= t'))) { > *(dest--) =3D 0; > } >=20 > It is better to do: >=20 > /* Remove trailing whitespaces, tabs, and CRs */ > while ((dest > last=5Fheader) && > ((*(dest-1) =3D=3D ' ') || (*(dest-1) =3D=3D '\r')|| (*(dest-= 1) =3D=3D=20 > '\t'))) { > *(--dest) =3D 0; > } >=20 > As I explained in that discussion on sourceforge.net, the difference is=20 > that my code will handle better the situation when the first instance of = > the header is empty. >=20 > Regards, >=20 > Anatoly. > > > > Charles, > > > >=20 > > > > This change was committed following this discussion :=20 > > http://sourceforge.net/tracker/index.php? > func=3Ddetail&aid=3D1733760&group=5Fid=3D104305&atid=3D637566=20 > > <http://sourceforge.net/tracker/index.php? > func=3Ddetail&aid=3D1733760&group=5Fid=3D104305&atid=3D637566>=20 > > > > > >=20 > > > > Olivier Boulkroune > > > >=20 > > > >=20 ------------------------------------------------------------------------ > > > > *De :* sip...@li...=20 > > [mailto:sip...@li...] *De la part de*=20 > > Charles P Wright > > *Envoy=E9 :* mercredi 1 ao=FBt 2007 16:11 > > *=C0 :* sip...@li...; oli...@hp... > > *Objet :* Re: [Sipp-devel] [Sipp-commits] SF.net SVN: sipp:=20 > > [292]sipp/trunk/call.cpp > > > >=20 > > > > > > Olivier, > > > > Do you know what the test case for r284 was? I found that the removal = > > of the dest--, prevented multiple headers from being properly included = > > in the last=5F keyword. > > > > Charles > > > > sip...@li... wrote on 08/01/2007=20 > > 10:03:30 AM: > > > > > Revision: 292 > > > http://sipp.svn.sourceforge.net/sipp/?rev=3D292&view=3Drev > > > Author: charlespwright > > > Date: 2007-08-01 07:03:30 -0700 (Wed, 01 Aug 2007) > > > > > > Log Message: > > > ----------- > > > Fix: last=5F* keyword should include multiple header instances (fixes > > > regression in r284). > > > > > > Modified Paths: > > > -------------- > > > sipp/trunk/call.cpp > > > > > > Modified: sipp/trunk/call.cpp > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sipp/trunk/call.cpp 2007-08-01 14:02:58 UTC (rev 291) > > > +++ sipp/trunk/call.cpp 2007-08-01 14:03:30 UTC (rev 292) > > > @@ -1095,6 +1095,7 @@ > > > // Add "," when several headers are present > > > if (dest !=3D last=5Fheader) { > > > /* Remove trailing whitespaces, tabs, and CRs */ > > > + *(dest--) =3D 0; > > > while ((dest > last=5Fheader) && > > > ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D '\= t'))) { > > > *(dest--) =3D 0; > > > > > > > > > This was sent by the SourceForge.net collaborative development > > > platform, the world's largest Open Source development site. > > > > > >=20 ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a=20 browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > Sipp-commits mailing list > > > Sip...@li... > > > https://lists.sourceforge.net/lists/listinfo/sipp-commits > > >=20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-08-08 16:32:02
|
Marc, =20 I found the problem and just committed a fix. It seems we exited only = one child, a 'else' keyword was too much. =20 Thanks for your help , =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : lundi 6 ao=FBt 2007 11:07 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] waitpid - was Next stable sipp release =20 Olivier, =20 I'm a little lost on this one. The change, correctly patched, only makes = a difference with the previous version in the occasion where the waitpid = is interrupted (by e.g. a USR2 signal), something you probably don't get = often. =20 Now, as in process_key there is (nearly) always a print_statistics after = the processing, which starts with a clear screen, it doesn't seem = strange to me that the key press effect disappears from the screen (but = is executed), as this part is handled in a separate thread. =20 So, if you're still convinced that it's the waitpid patch causing a bad = program behaviour, I see three options to continue on this: =20 1. try the effect of replacing the "while ((ret=3Dwaitpid" by "if = ((ret=3Dwaitpid" (this is the main difference, the rest of the code only = adds more verbose errors). A difference could prove my reasoning in the = first paragraph being wrong. =20 2. split the patch in parts to see where it comes from =20 3. create a tar with a kind of full "environment" so I could simulate = this on a stand alone linux machine (might be very hard, I know) and try = 1 and 2 myself =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 01 August 2007 18:07 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Hello Marc, =20 I checked the fix. The 'q' key behaves now normally, but the problem = with the 'p' key as well as with the change screen keys is still = remaining..... =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : vendredi 27 juillet 2007 18:23 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Marc, =20 Thanks for this, I'll test this change as soon as I can. =20 You can download the full source code of a given revision with a svn = client: svn export -r 280 = https://sipp.svn.sourceforge.net/svnroot/sipp/sipp/trunk sipp.svn.280 Some useful doc about SVN commands: = http://svnbook.red-bean.com/en/1.0/index.html=20 =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : vendredi 27 juillet 2007 10:42 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs between revisions 279 and 280, and found at least an = error in the modifications that could cause a lot of "unexplainable" = things: the exit of the first child was moved to the code for the second = child. =20 I'm not sure this is also the cause of the problem described below, but = please adapt as in the diff below and let me know. =20 I also have a question for the revisions and documentation: after some = searching I found a way to get the call.cpp source file for the given = revisions (in http://sipp.svn.sourceforge.net/viewvc/sipp/...), but I = didn't find a way to download the full source code of a given revision. = Some docs (for dummies;-) how to do this would be nice. That's why I = couldn't execute a compile+test check on the diff below. =20 =20 Best regards, =20 MarcVD =20 =20 A diff on call.cpp revision 280: --- call.cpp.280 2007-07-27 09:37:16.000000000 +0200 +++ call.cpp.280.new 2007-07-27 09:42:14.000000000 +0200 @@ -3182,13 +3182,13 @@ if((l_pid =3D fork()) < 0) { ERROR_NO("Forking error child"); } else { - int ret; if(l_pid =3D=3D 0){ + int ret; ret =3D system(x); // second child runs if(ret =3D=3D -1) { WARNING_P1("system call error for %s",x); - }else exit(EXIT_OTHER); } + } else exit(EXIT_OTHER);// first child exits } break; default: =20 =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 25 July 2007 18:10 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 I note the following behaviour with the revision 280 (as well as with = the latest one) : when pressing 'q' key, the quitting message is = displayed during less than one second, then disappears and the traffic = screen message comes back, as the key had not been pressed. The tool = behaves similarly when pressing the 'p' key, with the corresponding = message briefely displayed. =20 The tool behaviour is normal when using the revision 279. I don't = remember me encountering any "waitpid error". Even with the 280 = revision, the key handling works well as long as the exec action has not = been executed. =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : mercredi 25 juillet 2007 15:41 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) ;-)=20 |
From: <mar...@be...> - 2007-08-06 09:07:02
|
Olivier, =20 I'm a little lost on this one. The change, correctly patched, only makes = a difference with the previous version in the occasion where the waitpid = is interrupted (by e.g. a USR2 signal), something you probably don't get = often. =20 Now, as in process_key there is (nearly) always a print_statistics after = the processing, which starts with a clear screen, it doesn't seem = strange to me that the key press effect disappears from the screen (but = is executed), as this part is handled in a separate thread. So, if you're still convinced that it's the waitpid patch causing a bad = program behaviour, I see three options to continue on this: =20 1. try the effect of replacing the "while ((ret=3Dwaitpid" by "if = ((ret=3Dwaitpid" (this is the main difference, the rest of the code only = adds more verbose errors). A difference could prove my reasoning in the = first paragraph being wrong. =20 2. split the patch in parts to see where it comes from =20 3. create a tar with a kind of full "environment" so I could simulate = this on a stand alone linux machine (might be very hard, I know) and try = 1 and 2 myself =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 01 August 2007 18:07 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Hello Marc, =20 I checked the fix. The 'q' key behaves now normally, but the problem = with the 'p' key as well as with the change screen keys is still = remaining..... =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : vendredi 27 juillet 2007 18:23 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Marc, =20 Thanks for this, I'll test this change as soon as I can. =20 You can download the full source code of a given revision with a svn = client: svn export -r 280 = https://sipp.svn.sourceforge.net/svnroot/sipp/sipp/trunk sipp.svn.280 Some useful doc about SVN commands: = http://svnbook.red-bean.com/en/1.0/index.html=20 =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : vendredi 27 juillet 2007 10:42 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs between revisions 279 and 280, and found at least an = error in the modifications that could cause a lot of "unexplainable" = things: the exit of the first child was moved to the code for the second = child. =20 I'm not sure this is also the cause of the problem described below, but = please adapt as in the diff below and let me know. =20 I also have a question for the revisions and documentation: after some = searching I found a way to get the call.cpp source file for the given = revisions (in http://sipp.svn.sourceforge.net/viewvc/sipp/...), but I = didn't find a way to download the full source code of a given revision. = Some docs (for dummies;-) how to do this would be nice. That's why I = couldn't execute a compile+test check on the diff below. =20 =20 Best regards, =20 MarcVD =20 =20 A diff on call.cpp revision 280: --- call.cpp.280 2007-07-27 09:37:16.000000000 +0200 +++ call.cpp.280.new 2007-07-27 09:42:14.000000000 +0200 @@ -3182,13 +3182,13 @@ if((l_pid =3D fork()) < 0) { ERROR_NO("Forking error child"); } else { - int ret; if(l_pid =3D=3D 0){ + int ret; ret =3D system(x); // second child runs if(ret =3D=3D -1) { WARNING_P1("system call error for %s",x); - }else exit(EXIT_OTHER); } + } else exit(EXIT_OTHER);// first child exits } break; default: =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 25 July 2007 18:10 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 I note the following behaviour with the revision 280 (as well as with = the latest one) : when pressing 'q' key, the quitting message is = displayed during less than one second, then disappears and the traffic = screen message comes back, as the key had not been pressed. The tool = behaves similarly when pressing the 'p' key, with the corresponding = message briefely displayed. =20 The tool behaviour is normal when using the revision 279. I don't = remember me encountering any "waitpid error". Even with the 280 = revision, the key handling works well as long as the exec action has not = been executed. =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : mercredi 25 juillet 2007 15:41 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) ;-)=20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-08-02 08:55:57
|
Hello Simon, =20 Welcome to the Sipp community. Could you submit a new patch following = this link = http://sourceforge.net/tracker/?group_id=3D104305&atid=3D637566 ? This = helps us tracking contributions. =20 Sipp is currently at a turning point, a huge number of changes and = improvements has been brought recently to the tool. We currently focus = on correcting some pending bugs and running non-regression tests. The = aim is to deliver a new stable sipp version as soon as we can. So, as a = consequence, the addition of user enhancements is currently frozen until = the next stable version is delivered (of course, bug fixes are welcome = :-) ). We'll review your patch then. =20 Thanks a lot for your contribution and best regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de Simon = Flannery Envoy=E9 : jeudi 2 ao=FBt 2007 08:50 =C0 : sip...@li... Objet : Re: [Sipp-devel] /sipp/trunk/scenario.cpp + get_time function = +update / patch =20 Hi dev team, =20 I should mention that I implemented this because in the = "/sipp/trunk/scenario.cpp" file it reads / prints: =20 ERROR_P2("%s, \"%s\" hh:mm:ss not implemented yet! \n", what, ptr); =20 and I needed to use the hh:mm:ss functionality. =20 Please reply with your comments. =20 Cheers, =20 Simon =20 On 8/1/07, Simon Flannery <sim...@gm...> wrote:=20 Hi dev team, =20 I new to using SIPp and I would love to help contribute back to the SIPp = community. There is currently a function in the file = "/sipp/trunk/scenario.cpp" called get_time that does not support the = xx:xx:xx time format. I have added code to implement this simple task.=20 =20 I'm not familiar with the proper procedure of submitting code, but it = would be easy for you guys to update the scenario.cpp file if you feel = that my implementation is correct. =20 Note that I removed the use of the standard "strtod" function in = preference to using the standard "strtol" function - so I hope that will = not break anything else. I have tested it using MS VS C++ 2005 = (professional, not express) and GNU g++ - see the attached file.=20 =20 /* This function returns a time in milliseconds from a string. * The multiplier is used to convert from the default input type into * milliseconds. For example, for seconds you should use 1000 and for * milliseconds use 1. */=20 long get_time(const char *ptr, const char *what, int multiplier) { char *endptr; long ret; long time[2]; ret =3D 0; /* Clear it. */ if (isdigit(*ptr) =3D=3D 0) { ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr); } ret =3D strtol(ptr, &endptr, 10); if (*endptr) { if (strcmp(endptr, "s") =3D=3D 0) { /* Seconds */ ret *=3D 1000; } else if (strcmp(endptr, "ms") =3D=3D 0) { /* Milliseconds. */=20 /* Nothing. */ } else if (strcmp(endptr, "m") =3D=3D 0) { /* Minutes. */ ret *=3D 60; ret *=3D 1000; } else if (strcmp(endptr, "h") =3D=3D 0) { /* Hours. */ ret *=3D 60;=20 ret *=3D 60; ret *=3D 1000; } else if (strstr(endptr, ":") !=3D NULL) { time[0] =3D ret; ret =3D strtol(++endptr, &endptr, 10); if (strstr(endptr, ":") !=3D NULL) {=20 time[1] =3D ret; ret =3D strtol(++endptr, &endptr, 10); if (!*endptr) { ret +=3D time[0] * 3600 + time[1] * 60; } else { ret =3D 0; ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr);=20 } } else if (!*endptr) { ret +=3D time[0] * 600; } else { ret =3D 0; ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr);=20 } } else { ret =3D 0; ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr); } } else { ret *=3D multiplier; } return ret; } I hope this helps and I hope I may help further in the future, =20 Simon =20 =20 =20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-08-02 08:49:30
|
Hello folks, =20 Following the e-mail below, I'd like to inform you that we aim at = delivering a robust stable sipp version (3.0) as soon as we can. As a = consequence, we decided to freeze the addition of user contributions = until the 3.0 version is delivered. By now, only bug fixes will be added = into the trunk. I ask people with commit access to act this way. =20 If you have any enhancement you'd like to share with the community, = please submit a patch following this link = http://sourceforge.net/tracker/?group_id=3D104305&atid=3D637566 : we'll = review it as soon as the 3.0 version is available.=20 =20 Thanks for your comprehension and best regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : mercredi 11 juillet 2007 16:37 =C0 : sip...@li... Cc : Sulpis, Michel Objet : [Sipp-devel] Next stable sipp release =20 Hello folks, =20 This e-mail is adressed to all sipp contributers. =20 Thanks to your great work, a lot of important enhancements and bug fixes = have been brought to sipp since 2.0 version was released, improving = greatly the tool performances. It's time now to plan the next stable = sipp release (3.0). =20 I'd like to know if some of you had some pending contributions they = intent to bring to sipp trunk. We'll see if these contributions can be = added before the next release. A deadline will be then fixed for the = enhancement commits, after which only bug fixes will be added. The aim = is to deliver a robust stable version. A non-regression test campaign = will be run to achieve this. =20 As we faced recently a lot of regression bugs, I'd like to attract your = attention to the importance of running some non-regression tests before = submitting important code changes (at least the embedded scenarios as = well as Linux/HP_UX compilation should still work) . =20 Some of these bugs are still pending. We currently work fixing them.=20 =20 Thanks everyone, =20 Olivier Boulkroune =20 |
From: Simon F. <sim...@gm...> - 2007-08-02 06:50:17
|
Hi dev team, I should mention that I implemented this because in the "/sipp/trunk/scenario.cpp" file it reads / prints: ERROR_P2("%s, \"%s\" hh:mm:ss not implemented yet!\n", what, ptr); and I needed to use the hh:mm:ss functionality. Please reply with your comments. Cheers, Simon On 8/1/07, Simon Flannery <sim...@gm...> wrote: > > Hi dev team, > > I new to using SIPp and I would love to help contribute back to the SIPp > community. There is currently a function in the file > "/sipp/trunk/scenario.cpp" called get_time that does not support the > xx:xx:xx time format. I have added code to implement this simple task. > > I'm not familiar with the proper procedure of submitting code, but it > would be easy for you guys to update the scenario.cpp file if you feel > that my implementation is correct. > > Note that I removed the use of the standard "strtod" function in > preference to using the standard "strtol" function - so I hope that will not > break anything else. I have tested it using MS VS C++ 2005 (professional, > not express) and GNU g++ - see the attached file. > > /* This function returns a time in milliseconds from a string. > * The multiplier is used to convert from the default input type into > * milliseconds. For example, for seconds you should use 1000 and for > * milliseconds use 1. */ > long get_time(const char *ptr, const char *what, int multiplier) { > char *endptr; > long ret; > long time[2]; > > ret = 0; /* Clear it. */ > if (isdigit(*ptr) == 0) { > ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr); > } > > ret = strtol(ptr, &endptr, 10); > if (*endptr) { > if (strcmp(endptr, "s") == 0) { /* Seconds */ > ret *= 1000; > } else if (strcmp(endptr, "ms") == 0) { /* Milliseconds. */ > /* Nothing. */ > } else if (strcmp(endptr, "m") == 0) { /* Minutes. */ > ret *= 60; > ret *= 1000; > } else if (strcmp(endptr, "h") == 0) { /* Hours. */ > ret *= 60; > ret *= 60; > ret *= 1000; > } else if (strstr(endptr, ":") != NULL) { > time[0] = ret; > ret = strtol(++endptr, &endptr, 10); > if (strstr(endptr, ":") != NULL) { > time[1] = ret; > ret = strtol(++endptr, &endptr, 10); > if (!*endptr) { > ret += time[0] * 3600 + time[1] * 60; > } else { > ret = 0; > ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr); > } > } else if (!*endptr) { > ret += time[0] * 600; > } > else { > ret = 0; > ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr); > } > } else { > ret = 0; > ERROR_P2("%s, \"%s\" is not a valid time!\n", what, ptr); > } > } else { > ret *= multiplier; > } > > return ret; > } > > I hope this helps and I hope I may help further in the future, > > > Simon > > > > |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-08-01 16:53:16
|
Oops......I corrected this in the latest revision (293). Sorry about = that. Thanks and regards, Olivier Boulkroune =20 -----Message d'origine----- De=A0: Anatoly Pidruchny [mailto:api...@ne...]=20 Envoy=E9=A0: mercredi 1 ao=FBt 2007 17:45 =C0=A0: Boulkroune, Olivier (Non-HP:Atos Origin) Cc=A0: Charles P Wright; sip...@li...; = api...@us... Objet=A0: Re: [Sipp-devel] [Sipp-commits] SF.net SVN: sipp: = [292]sipp/trunk/call.cpp Olivier, sorry that I did not verify that earlier. But you did not apply my patch = correctly! Below is the part from my proposed patch. Please pay=20 attention to the two modified lines that start from '!' character: *************** *** 1174,1192 **** // Add "," when several headers are present if (dest !=3D last_header) { /* Remove trailing whitespaces, tabs, and CRs */ - *(dest--) =3D 0; while ((dest > last_header) && ! ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D = '\t'))) { ! *(dest--) =3D 0; } =20 dest +=3D sprintf(dest, ","); - - /* We only want to append the contents of the header, not its=20 name for - * the second value. */ - if (!content) { - src +=3D strlen(name); - } } dest +=3D sprintf(dest, "%s", src); if(ptr) { *ptr =3D '\n'; } --- 1176,1187 ---- // Add "," when several headers are present if (dest !=3D last_header) { /* Remove trailing whitespaces, tabs, and CRs */ while ((dest > last_header) && ! ((*(dest-1) =3D=3D ' ') || (*(dest-1) =3D=3D '\r')|| = (*(dest-1) =3D=3D=20 '\t'))) { ! *(--dest) =3D 0; } =20 dest +=3D sprintf(dest, ","); } dest +=3D sprintf(dest, "%s", src); if(ptr) { *ptr =3D '\n'; } In revision 284 of call.cpp file you removed the "*(dest--) =3D 0;", but = you did not modify these two lines. Of course this causes the problem. I = still think that it is better to do this my way. Instead of: /* Remove trailing whitespaces, tabs, and CRs */ *(dest--) =3D 0; while ((dest > last_header) && ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D = '\t'))) { *(dest--) =3D 0; } It is better to do: /* Remove trailing whitespaces, tabs, and CRs */ while ((dest > last_header) && ((*(dest-1) =3D=3D ' ') || (*(dest-1) =3D=3D '\r')|| = (*(dest-1) =3D=3D=20 '\t'))) { *(--dest) =3D 0; } As I explained in that discussion on sourceforge.net, the difference is=20 that my code will handle better the situation when the first instance of = the header is empty. Regards, Anatoly. > > Charles, > > =20 > > This change was committed following this discussion :=20 > = http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1733760&grou= p_id=3D104305&atid=3D637566=20 > = <http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1733760&gro= up_id=3D104305&atid=3D637566>=20 > > > =20 > > Olivier Boulkroune > > =20 > > = ------------------------------------------------------------------------ > > *De :* sip...@li...=20 > [mailto:sip...@li...] *De la part de*=20 > Charles P Wright > *Envoy=E9 :* mercredi 1 ao=FBt 2007 16:11 > *=C0 :* sip...@li...; oli...@hp... > *Objet :* Re: [Sipp-devel] [Sipp-commits] SF.net SVN: sipp:=20 > [292]sipp/trunk/call.cpp > > =20 > > > Olivier, > > Do you know what the test case for r284 was? I found that the removal = > of the dest--, prevented multiple headers from being properly included = > in the last_ keyword. > > Charles > > sip...@li... wrote on 08/01/2007=20 > 10:03:30 AM: > > > Revision: 292 > > http://sipp.svn.sourceforge.net/sipp/?rev=3D292&view=3Drev > > Author: charlespwright > > Date: 2007-08-01 07:03:30 -0700 (Wed, 01 Aug 2007) > > > > Log Message: > > ----------- > > Fix: last_* keyword should include multiple header instances (fixes > > regression in r284). > > > > Modified Paths: > > -------------- > > sipp/trunk/call.cpp > > > > Modified: sipp/trunk/call.cpp > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sipp/trunk/call.cpp 2007-08-01 14:02:58 UTC (rev 291) > > +++ sipp/trunk/call.cpp 2007-08-01 14:03:30 UTC (rev 292) > > @@ -1095,6 +1095,7 @@ > > // Add "," when several headers are present > > if (dest !=3D last_header) { > > /* Remove trailing whitespaces, tabs, and CRs */ > > + *(dest--) =3D 0; > > while ((dest > last_header) && > > ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D = '\t'))) { > > *(dest--) =3D 0; > > > > > > This was sent by the SourceForge.net collaborative development > > platform, the world's largest Open Source development site. > > > > = -------------------------------------------------------------------------= > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a = browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Sipp-commits mailing list > > Sip...@li... > > https://lists.sourceforge.net/lists/listinfo/sipp-commits > |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-08-01 16:06:58
|
Hello Marc, =20 I checked the fix. The 'q' key behaves now normally, but the problem = with the 'p' key as well as with the change screen keys is still = remaining..... =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : vendredi 27 juillet 2007 18:23 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Marc, =20 Thanks for this, I'll test this change as soon as I can. =20 You can download the full source code of a given revision with a svn = client: svn export -r 280 = https://sipp.svn.sourceforge.net/svnroot/sipp/sipp/trunk sipp.svn.280 Some useful doc about SVN commands: = http://svnbook.red-bean.com/en/1.0/index.html=20 =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : vendredi 27 juillet 2007 10:42 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs between revisions 279 and 280, and found at least an = error in the modifications that could cause a lot of "unexplainable" = things: the exit of the first child was moved to the code for the second = child. =20 I'm not sure this is also the cause of the problem described below, but = please adapt as in the diff below and let me know. =20 I also have a question for the revisions and documentation: after some = searching I found a way to get the call.cpp source file for the given = revisions (in http://sipp.svn.sourceforge.net/viewvc/sipp/...), but I = didn't find a way to download the full source code of a given revision. = Some docs (for dummies;-) how to do this would be nice. That's why I = couldn't execute a compile+test check on the diff below. =20 =20 Best regards, =20 MarcVD =20 =20 A diff on call.cpp revision 280: --- call.cpp.280 2007-07-27 09:37:16.000000000 +0200 +++ call.cpp.280.new 2007-07-27 09:42:14.000000000 +0200 @@ -3182,13 +3182,13 @@ if((l_pid =3D fork()) < 0) { ERROR_NO("Forking error child"); } else { - int ret; if(l_pid =3D=3D 0){ + int ret; ret =3D system(x); // second child runs if(ret =3D=3D -1) { WARNING_P1("system call error for %s",x); - }else exit(EXIT_OTHER); } + } else exit(EXIT_OTHER);// first child exits } break; default: =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 25 July 2007 18:10 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 I note the following behaviour with the revision 280 (as well as with = the latest one) : when pressing 'q' key, the quitting message is = displayed during less than one second, then disappears and the traffic = screen message comes back, as the key had not been pressed. The tool = behaves similarly when pressing the 'p' key, with the corresponding = message briefely displayed. =20 The tool behaviour is normal when using the revision 279. I don't = remember me encountering any "waitpid error". Even with the 280 = revision, the key handling works well as long as the exec action has not = been executed. =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : mercredi 25 juillet 2007 15:41 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) ;-)=20 |
From: Anatoly P. <api...@ne...> - 2007-08-01 15:46:15
|
Olivier, sorry that I did not verify that earlier. But you did not apply my patch correctly! Below is the part from my proposed patch. Please pay attention to the two modified lines that start from '!' character: *************** *** 1174,1192 **** // Add "," when several headers are present if (dest != last_header) { /* Remove trailing whitespaces, tabs, and CRs */ - *(dest--) = 0; while ((dest > last_header) && ! ((*dest == ' ') || (*dest == '\r')|| (*dest == '\t'))) { ! *(dest--) = 0; } dest += sprintf(dest, ","); - - /* We only want to append the contents of the header, not its name for - * the second value. */ - if (!content) { - src += strlen(name); - } } dest += sprintf(dest, "%s", src); if(ptr) { *ptr = '\n'; } --- 1176,1187 ---- // Add "," when several headers are present if (dest != last_header) { /* Remove trailing whitespaces, tabs, and CRs */ while ((dest > last_header) && ! ((*(dest-1) == ' ') || (*(dest-1) == '\r')|| (*(dest-1) == '\t'))) { ! *(--dest) = 0; } dest += sprintf(dest, ","); } dest += sprintf(dest, "%s", src); if(ptr) { *ptr = '\n'; } In revision 284 of call.cpp file you removed the "*(dest--) = 0;", but you did not modify these two lines. Of course this causes the problem. I still think that it is better to do this my way. Instead of: /* Remove trailing whitespaces, tabs, and CRs */ *(dest--) = 0; while ((dest > last_header) && ((*dest == ' ') || (*dest == '\r')|| (*dest == '\t'))) { *(dest--) = 0; } It is better to do: /* Remove trailing whitespaces, tabs, and CRs */ while ((dest > last_header) && ((*(dest-1) == ' ') || (*(dest-1) == '\r')|| (*(dest-1) == '\t'))) { *(--dest) = 0; } As I explained in that discussion on sourceforge.net, the difference is that my code will handle better the situation when the first instance of the header is empty. Regards, Anatoly. > > Charles, > > > > This change was committed following this discussion : > http://sourceforge.net/tracker/index.php?func=detail&aid=1733760&group_id=104305&atid=637566 > <http://sourceforge.net/tracker/index.php?func=detail&aid=1733760&group_id=104305&atid=637566> > > > > > Olivier Boulkroune > > > > ------------------------------------------------------------------------ > > *De :* sip...@li... > [mailto:sip...@li...] *De la part de* > Charles P Wright > *Envoyé :* mercredi 1 août 2007 16:11 > *À :* sip...@li...; oli...@hp... > *Objet :* Re: [Sipp-devel] [Sipp-commits] SF.net SVN: sipp: > [292]sipp/trunk/call.cpp > > > > > Olivier, > > Do you know what the test case for r284 was? I found that the removal > of the dest--, prevented multiple headers from being properly included > in the last_ keyword. > > Charles > > sip...@li... wrote on 08/01/2007 > 10:03:30 AM: > > > Revision: 292 > > http://sipp.svn.sourceforge.net/sipp/?rev=292&view=rev > > Author: charlespwright > > Date: 2007-08-01 07:03:30 -0700 (Wed, 01 Aug 2007) > > > > Log Message: > > ----------- > > Fix: last_* keyword should include multiple header instances (fixes > > regression in r284). > > > > Modified Paths: > > -------------- > > sipp/trunk/call.cpp > > > > Modified: sipp/trunk/call.cpp > > =================================================================== > > --- sipp/trunk/call.cpp 2007-08-01 14:02:58 UTC (rev 291) > > +++ sipp/trunk/call.cpp 2007-08-01 14:03:30 UTC (rev 292) > > @@ -1095,6 +1095,7 @@ > > // Add "," when several headers are present > > if (dest != last_header) { > > /* Remove trailing whitespaces, tabs, and CRs */ > > + *(dest--) = 0; > > while ((dest > last_header) && > > ((*dest == ' ') || (*dest == '\r')|| (*dest == '\t'))) { > > *(dest--) = 0; > > > > > > This was sent by the SourceForge.net collaborative development > > platform, the world's largest Open Source development site. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Sipp-commits mailing list > > Sip...@li... > > https://lists.sourceforge.net/lists/listinfo/sipp-commits > |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-08-01 14:44:52
|
Charles, =20 This change was committed following this discussion : = http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1733760&grou= p_id=3D104305&atid=3D637566=20 =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de Charles = P Wright Envoy=E9 : mercredi 1 ao=FBt 2007 16:11 =C0 : sip...@li...; oli...@hp... Objet : Re: [Sipp-devel] [Sipp-commits] SF.net SVN: sipp: = [292]sipp/trunk/call.cpp =20 Olivier,=20 Do you know what the test case for r284 was? I found that the removal = of the dest--, prevented multiple headers from being properly included = in the last_ keyword.=20 Charles=20 sip...@li... wrote on 08/01/2007 10:03:30 = AM: > Revision: 292 > http://sipp.svn.sourceforge.net/sipp/?rev=3D292&view=3Drev > Author: charlespwright > Date: 2007-08-01 07:03:30 -0700 (Wed, 01 Aug 2007) >=20 > Log Message: > ----------- > Fix: last_* keyword should include multiple header instances (fixes=20 > regression in r284). >=20 > Modified Paths: > -------------- > sipp/trunk/call.cpp >=20 > Modified: sipp/trunk/call.cpp > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sipp/trunk/call.cpp 2007-08-01 14:02:58 UTC (rev 291) > +++ sipp/trunk/call.cpp 2007-08-01 14:03:30 UTC (rev 292) > @@ -1095,6 +1095,7 @@ > // Add "," when several headers are present > if (dest !=3D last_header) { > /* Remove trailing whitespaces, tabs, and CRs */ > + *(dest--) =3D 0; > while ((dest > last_header) && > ((*dest =3D=3D ' ') || (*dest =3D=3D '\r')|| (*dest =3D=3D = '\t'))) { > *(dest--) =3D 0; >=20 >=20 > This was sent by the SourceForge.net collaborative development=20 > platform, the world's largest Open Source development site. >=20 > = -------------------------------------------------------------------------= > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a = browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sipp-commits mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/sipp-commits |
From: Charles P W. <cpw...@us...> - 2007-08-01 14:12:13
|
Olivier, Do you know what the test case for r284 was? I found that the removal of the dest--, prevented multiple headers from being properly included in the last_ keyword. Charles sip...@li... wrote on 08/01/2007 10:03:30 AM: > Revision: 292 > http://sipp.svn.sourceforge.net/sipp/?rev=292&view=rev > Author: charlespwright > Date: 2007-08-01 07:03:30 -0700 (Wed, 01 Aug 2007) > > Log Message: > ----------- > Fix: last_* keyword should include multiple header instances (fixes > regression in r284). > > Modified Paths: > -------------- > sipp/trunk/call.cpp > > Modified: sipp/trunk/call.cpp > =================================================================== > --- sipp/trunk/call.cpp 2007-08-01 14:02:58 UTC (rev 291) > +++ sipp/trunk/call.cpp 2007-08-01 14:03:30 UTC (rev 292) > @@ -1095,6 +1095,7 @@ > // Add "," when several headers are present > if (dest != last_header) { > /* Remove trailing whitespaces, tabs, and CRs */ > + *(dest--) = 0; > while ((dest > last_header) && > ((*dest == ' ') || (*dest == '\r')|| (*dest == '\t'))) { > *(dest--) = 0; > > > This was sent by the SourceForge.net collaborative development > platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sipp-commits mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/sipp-commits |
From: Simon F. <sim...@gm...> - 2007-08-01 12:15:50
|
I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8c3RyaW5n Lmg+DQojaW5jbHVkZSA8Y3R5cGUuaD4NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCg0KI2RlZmluZSBF UlJPUl9QMiBwcmludGYNCg0KLyogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGEgdGltZSBpbiBtaWxs aXNlY29uZHMgZnJvbSBhIHN0cmluZy4NCiAqIFRoZSBtdWx0aXBsaWVyIGlzIHVzZWQgdG8gY29u dmVydCBmcm9tIHRoZSBkZWZhdWx0IGlucHV0IHR5cGUgaW50bw0KICogbWlsbGlzZWNvbmRzLiBG b3IgZXhhbXBsZSwgZm9yIHNlY29uZHMgeW91IHNob3VsZCB1c2UgMTAwMCBhbmQgZm9yDQogKiBt aWxsaXNlY29uZHMgdXNlIDEuICovDQpsb25nIGdldF90aW1lKGNvbnN0IGNoYXIgKnB0ciwgY29u c3QgY2hhciAqd2hhdCwgaW50IG11bHRpcGxpZXIpIHsNCiAgY2hhciAqZW5kcHRyOw0KICBsb25n IHJldDsNCiAgbG9uZyB0aW1lWzJdOw0KDQogIHJldCA9IDA7IC8qIENsZWFyIGl0LiAqLw0KICBp ZiAoaXNkaWdpdCgqcHRyKSA9PSAwKSB7DQogICAgRVJST1JfUDIoIiVzLCBcIiVzXCIgaXMgbm90 IGEgdmFsaWQgdGltZSFcbiIsIHdoYXQsIHB0cik7DQogIH0NCg0KICByZXQgPSBzdHJ0b2wocHRy LCAmZW5kcHRyLCAxMCk7DQogIGlmICgqZW5kcHRyKSB7DQogICAgaWYgKHN0cmNtcChlbmRwdHIs ICJzIikgPT0gMCkgeyAvKiBTZWNvbmRzICovDQogICAgICByZXQgKj0gMTAwMDsNCiAgICB9IGVs c2UgaWYgKHN0cmNtcChlbmRwdHIsICJtcyIpID09IDApIHsgLyogTWlsbGlzZWNvbmRzLiAqLw0K ICAgICAgLyogTm90aGluZy4gKi8NCiAgICB9IGVsc2UgaWYgKHN0cmNtcChlbmRwdHIsICJtIikg PT0gMCkgeyAvKiBNaW51dGVzLiAqLw0KICAgICAgcmV0ICo9IDYwOw0KICAgICAgcmV0ICo9IDEw MDA7DQogICAgfSBlbHNlIGlmIChzdHJjbXAoZW5kcHRyLCAiaCIpID09IDApIHsgLyogSG91cnMu ICovDQogICAgICByZXQgKj0gNjA7DQogICAgICByZXQgKj0gNjA7DQogICAgICByZXQgKj0gMTAw MDsNCiAgICB9IGVsc2UgaWYgKHN0cnN0cihlbmRwdHIsICI6IikgIT0gTlVMTCkgew0KICAgICAg IHRpbWVbMF0gPSByZXQ7DQogICAgICAgcmV0ID0gc3RydG9sKCsrZW5kcHRyLCAmZW5kcHRyLCAx MCk7DQogICAgICAgaWYgKHN0cnN0cihlbmRwdHIsICI6IikgIT0gTlVMTCkgew0KICAgICAgICAg dGltZVsxXSA9IHJldDsNCiAgICAgICAgIHJldCA9IHN0cnRvbCgrK2VuZHB0ciwgJmVuZHB0ciwg MTApOw0KICAgICAgICAgaWYgKCEqZW5kcHRyKSB7DQogICAgICAgICAgIHJldCArPSB0aW1lWzBd ICogMzYwMCArIHRpbWVbMV0gKiA2MDsNCiAgICAgICAgIH0gZWxzZSB7DQogICAgICAgICAgIHJl dCA9IDA7DQogICAgICAgICAgIEVSUk9SX1AyKCIlcywgXCIlc1wiIGlzIG5vdCBhIHZhbGlkIHRp bWUhXG4iLCB3aGF0LCBwdHIpOw0KICAgICAgICAgfQ0KICAgICAgIH0gZWxzZSBpZiAoISplbmRw dHIpIHsNCiAgICAgICAgIHJldCArPSB0aW1lWzBdICogNjAwOw0KICAgICAgIH0NCiAgICAgICBl bHNlIHsNCiAgICAgICAgIHJldCA9IDA7DQogICAgICAgICBFUlJPUl9QMigiJXMsIFwiJXNcIiBp cyBub3QgYSB2YWxpZCB0aW1lIVxuIiwgd2hhdCwgcHRyKTsNCiAgICAgICB9DQogICAgfSBlbHNl IHsNCiAgICAgIHJldCA9IDA7DQogICAgICBFUlJPUl9QMigiJXMsIFwiJXNcIiBpcyBub3QgYSB2 YWxpZCB0aW1lIVxuIiwgd2hhdCwgcHRyKTsNCiAgICB9DQogIH0gZWxzZSB7DQogICAgcmV0ICo9 IG11bHRpcGxpZXI7DQogIH0NCg0KICByZXR1cm4gcmV0Ow0KfQ0KDQppbnQgbWFpbihpbnQgYXJn YywgY2hhciogYXJndltdKQ0Kew0KICBsb25nIGEgPSBnZXRfdGltZSgiMTIzNCIsICJFcnJvciIs IDEwMDApOw0KICBhc3NlcnQoYSA9PSAxMjM0MDAwKTsNCiAgbG9uZyBiID0gZ2V0X3RpbWUoIjEy MzQiLCAiRXJyb3IiLCAxKTsNCiAgYXNzZXJ0KGIgPT0gMTIzNCk7DQogIGxvbmcgYyA9IGdldF90 aW1lKCIxMjM0IiwgIkVycm9yIiwgMCk7DQogIGFzc2VydChjID09IDApOw0KICBsb25nIGQgPSBn ZXRfdGltZSgiMTIzNCIsICJFcnJvciIsIC0xKTsNCiAgYXNzZXJ0KGEgIT0gLTEyMzQpOw0KICBs b25nIGUgPSBnZXRfdGltZSgiMTIzNG1zIiwgIkVycm9yIiwgMTAwMCk7DQogIGFzc2VydChlID09 IDEyMzQpOw0KICBsb25nIGYgPSBnZXRfdGltZSgiMTIzNHMiLCAiRXJyb3IiLCAxMDAwKTsNCiAg YXNzZXJ0KGYgPT0gMTIzNDAwMCk7DQogIGxvbmcgZyA9IGdldF90aW1lKCIxMjM0bSIsICJFcnJv ciIsIDEwMDApOw0KICBhc3NlcnQoZyA9PSA3NDA0MDAwMCk7DQogIGxvbmcgaCA9IGdldF90aW1l KCIxMjNoIiwgIkVycm9yIiwgMTAwMCk7DQogIGFzc2VydChoID09IDQ0MjgwMDAwMCk7IC8qIExP TkdfTUFYIGlzIGxpbWl0ZWQgdG8gb25seSAyMTQ3NDgzNjQ3LiAqLw0KICBsb25nIGkgPSBnZXRf dGltZSgiMDA6MDA6MTAiLCAiRXJyb3IiLCAxMDAwKTsNCiAgYXNzZXJ0KGkgPT0gMTApOw0KICBs b25nIGogPSBnZXRfdGltZSgiMDA6MTA6MTAiLCAiRXJyb3IiLCAxMDAwKTsNCiAgYXNzZXJ0KGog PT0gNjEwKTsNCiAgbG9uZyBrID0gZ2V0X3RpbWUoIjEwOjEwOjEwIiwgIkVycm9yIiwgMTAwMCk7 DQogIGFzc2VydChrID09IDM2NjEwKTsNCiAgbG9uZyBsID0gZ2V0X3RpbWUoIjAwOjEwIiwgIkVy cm9yIiwgMTAwMCk7DQogIGFzc2VydChsID09IDEwKTsNCiAgbG9uZyBtID0gZ2V0X3RpbWUoIjAx OjE6MTAiLCAiRXJyb3IiLCAxMDAwKTsNCiAgYXNzZXJ0KG0gPT0gMzY3MCk7DQogIGxvbmcgbiA9 IGdldF90aW1lKCIxOjEwOjEwIiwgIkVycm9yIiwgMTAwMCk7DQogIGFzc2VydChuID09IDQyMTAp Ow0KDQogIGxvbmcgbyA9IGdldF90aW1lKCIxOjEwOjEwaCIsICJFcnJvciIsIDEwMDApOw0KICBh c3NlcnQobyA9PSAwKTsNCiAgbG9uZyBwID0gZ2V0X3RpbWUoIjoxMDoxIiwgIkVycm9yIiwgMTAw MCk7DQogIGFzc2VydChwID09IDYwMSk7IC8qIE5PVCB6ZXJvIC0gQnkgZGVzaWduLiAqLw0KDQog IHJldHVybiAwOw0KfQ0K |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-07-27 16:23:11
|
Marc, =20 Thanks for this, I'll test this change as soon as I can. =20 You can download the full source code of a given revision with a svn = client: svn export -r 280 = https://sipp.svn.sourceforge.net/svnroot/sipp/sipp/trunk sipp.svn.280 Some useful doc about SVN commands: = http://svnbook.red-bean.com/en/1.0/index.html=20 =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : vendredi 27 juillet 2007 10:42 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs between revisions 279 and 280, and found at least an = error in the modifications that could cause a lot of "unexplainable" = things: the exit of the first child was moved to the code for the second = child. =20 I'm not sure this is also the cause of the problem described below, but = please adapt as in the diff below and let me know. =20 I also have a question for the revisions and documentation: after some = searching I found a way to get the call.cpp source file for the given = revisions (in http://sipp.svn.sourceforge.net/viewvc/sipp/...), but I = didn't find a way to download the full source code of a given revision. = Some docs (for dummies;-) how to do this would be nice. That's why I = couldn't execute a compile+test check on the diff below. =20 =20 Best regards, =20 MarcVD =20 =20 A diff on call.cpp revision 280: --- call.cpp.280 2007-07-27 09:37:16.000000000 +0200 +++ call.cpp.280.new 2007-07-27 09:42:14.000000000 +0200 @@ -3182,13 +3182,13 @@ if((l_pid =3D fork()) < 0) { ERROR_NO("Forking error child"); } else { - int ret; if(l_pid =3D=3D 0){ + int ret; ret =3D system(x); // second child runs if(ret =3D=3D -1) { WARNING_P1("system call error for %s",x); - }else exit(EXIT_OTHER); } + } else exit(EXIT_OTHER);// first child exits } break; default: =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 25 July 2007 18:10 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 I note the following behaviour with the revision 280 (as well as with = the latest one) : when pressing 'q' key, the quitting message is = displayed during less than one second, then disappears and the traffic = screen message comes back, as the key had not been pressed. The tool = behaves similarly when pressing the 'p' key, with the corresponding = message briefely displayed. =20 The tool behaviour is normal when using the revision 279. I don't = remember me encountering any "waitpid error". Even with the 280 = revision, the key handling works well as long as the exec action has not = been executed. =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : mercredi 25 juillet 2007 15:41 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) ;-)=20 |
From: <mar...@be...> - 2007-07-27 08:41:52
|
Olivier, =20 I checked the diffs between revisions 279 and 280, and found at least an = error in the modifications that could cause a lot of "unexplainable" = things: the exit of the first child was moved to the code for the second = child. =20 I'm not sure this is also the cause of the problem described below, but = please adapt as in the diff below and let me know. =20 I also have a question for the revisions and documentation: after some = searching I found a way to get the call.cpp source file for the given = revisions (in http://sipp.svn.sourceforge.net/viewvc/sipp/...), but I = didn't find a way to download the full source code of a given revision. = Some docs (for dummies;-) how to do this would be nice. That's why I = couldn't execute a compile+test check on the diff below. =20 =20 Best regards, =20 MarcVD =20 =20 A diff on call.cpp revision 280: --- call.cpp.280 2007-07-27 09:37:16.000000000 +0200 +++ call.cpp.280.new 2007-07-27 09:42:14.000000000 +0200 @@ -3182,13 +3182,13 @@ if((l_pid =3D fork()) < 0) { ERROR_NO("Forking error child"); } else { - int ret; if(l_pid =3D=3D 0){ + int ret; ret =3D system(x); // second child runs if(ret =3D=3D -1) { WARNING_P1("system call error for %s",x); - }else exit(EXIT_OTHER); } + } else exit(EXIT_OTHER);// first child exits } break; default: =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 25 July 2007 18:10 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 I note the following behaviour with the revision 280 (as well as with = the latest one) : when pressing 'q' key, the quitting message is = displayed during less than one second, then disappears and the traffic = screen message comes back, as the key had not been pressed. The tool = behaves similarly when pressing the 'p' key, with the corresponding = message briefely displayed. =20 The tool behaviour is normal when using the revision 279. I don't = remember me encountering any "waitpid error". Even with the 280 = revision, the key handling works well as long as the exec action has not = been executed. =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : mercredi 25 juillet 2007 15:41 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) ;-)=20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-07-25 16:10:22
|
Marc, =20 I note the following behaviour with the revision 280 (as well as with = the latest one) : when pressing 'q' key, the quitting message is = displayed during less than one second, then disappears and the traffic = screen message comes back, as the key had not been pressed. The tool = behaves similarly when pressing the 'p' key, with the corresponding = message briefely displayed. =20 The tool behaviour is normal when using the revision 279. I don't = remember me encountering any "waitpid error". Even with the 280 = revision, the key handling works well as long as the exec action has not = been executed. =20 Thanks and regards, =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : mercredi 25 juillet 2007 15:41 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : RE: [Sipp-devel] Next stable sipp release =20 Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) +32 2 244 5078 ;-)=20 |
From: <mar...@be...> - 2007-07-25 13:41:12
|
Olivier, =20 I checked the diffs I sent, and the only relevant difference (except for = more info in the error messages) is a while loop waiting for the first = child to exit; it replaces an if statement doing the same waiting once. = The reason for the loop is that signals (like USR2) also stop the = waiting even if the child has not yet exited, so the waiting should = continue in that case. As long as no signal arrives during the lifetime = of the intermediate first child, there should be no difference at all = between the if and the while. =20 As the character input of the program is not handled by signals (but in = a thread), I don't see an immediate relation (I'm no thread specialist, = and I hope the threads do continue and not just throw away the input = while the main program is waiting). =20 >From the example below, I can deduce that the machine will in total = spawn at least 4 children (one intermediate (for sipp zombie cleanup), = one doing the command/shell (&), one sipp spawning the final one in = background (-bg) and the final one). This can take some time for the = machine to be ready with it, and as long as the first child has not = exited, the main process will wait. =20 Is it this waiting time that is meant with "on the first instance", or = is there a first keystroke not being handled? =20 So, please give some more info on the difference in behaviour between = the two versions. Did you ever get a "waitpid error" in revision 279 = (only in this case the loop is entered)?=20 =20 Best regards, =20 MarcVD ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 23 July 2007 18:49 To: mar...@be... Cc: sip...@li... Subject: RE: [Sipp-devel] Next stable sipp release Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) +32 2 244 5078 ;-)=20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-07-23 16:49:19
|
Marc, =20 It seems this commit brought the following problem : =20 I have a scenario where one sipp instance launches two other sipp = instances in 3pcc, something like =20 <nop> <action> <exec command=3D"/sipp XXXX:5060 -i [LOCAL_IP] -p [field8] -s = [field0] -sf 3pccSut.xml -fd 60 -3pcc XXXX:[field12] -r = [CALLRATE_CONFERENCEE] -m [field4] -l [field4] -mp [field9] = [TRACES_CONFERENCEE_SUT] -base_cseq 200 -aa -bg &"/> </action> </nop> =20 When the command has been executed, the 'p' and 'q' keys press does not = work anymore on the first instance. The problem occurs since revision = 280 (revision 279 works fine). Could you have a look on this ? =20 Thans and regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Boulkroune, Olivier (Non-HP:Atos Origin) Envoy=E9 : jeudi 12 juillet 2007 09:57 =C0 : mar...@be... Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) +32 2 244 5078 ;-)=20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-07-17 08:26:34
|
Charles, =20 I continue this discussion on the sipp-devel mailing-list. =20 You're right. I wrote this function quickly to face an urgent need for = updating the automatic messages sent by sipp, but it needs to be = rewritten properly to handle every situations. =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de Charles = P Wright Envoy=E9 : mardi 17 juillet 2007 06:47 =C0 : sip...@li... Objet : [Sipp-users] get_last_request_uri =20 The call::get_last_request_uri returns the URI from the To field rather = than the request URI of the message. Is there any reason to keep this = behavior, as in some circumstances the request URI may not match the To = field (e.g., in a REGISTER request). I think we should update the = function to get the actual request URI, but want to get some opinions = before I do that.=20 Charles |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-07-12 07:58:39
|
1) Checked-in (rev 280). =20 Thanks a lot Marc. =20 Olivier Boulkroune =20 ________________________________ De : mar...@be... [mailto:mar...@be...]=20 Envoy=E9 : jeudi 12 juillet 2007 09:06 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Cc : sip...@li... Objet : Re: [Sipp-devel] Next stable sipp release =20 Olivier,=20 1) there should still be a bug fix hanging around for "sipp fix for = interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I = didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) = generated when launching unix commands.=20 Best regards,=20 MarcVD=20 (-: from Marc VAN DIEST (BELGACOM) +32 2 244 5078 ;-)=20 |
From: <mar...@be...> - 2007-07-12 07:05:50
|
Olivier, 1) there should still be a bug fix hanging around for "sipp fix for interrupted waitpid() case" (mail of mine dated 14/05/2007), at least I didn't get/see any reaction on this until now. 2) sorry, I didn't find the time yet to look at the extra ^M (<CR>) generated when launching unix commands. Best regards, MarcVD (-: from Marc VAN DIEST (BELGACOM) +32 2 244 5078 ;-) |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-07-11 14:36:54
|
Hello folks, =20 This e-mail is adressed to all sipp contributers. =20 Thanks to your great work, a lot of important enhancements and bug fixes have been brought to sipp since 2.0 version was released, improving greatly the tool performances. It's time now to plan the next stable sipp release (3.0). =20 I'd like to know if some of you had some pending contributions they intent to bring to sipp trunk. We'll see if these contributions can be added before the next release. A deadline will be then fixed for the enhancement commits, after which only bug fixes will be added. The aim is to deliver a robust stable version. A non-regression test campaign will be run to achieve this. =20 As we faced recently a lot of regression bugs, I'd like to attract your attention to the importance of running some non-regression tests before submitting important code changes (at least the embedded scenarios as well as Linux/HP_UX compilation should still work) . =20 Some of these bugs are still pending. We currently work fixing them.=20 =20 Thanks everyone, =20 Olivier Boulkroune =20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-06-26 15:20:45
|
Thanks a lot Hemanth ! I'll have a look at it soon. =20 Best regards, Olivier Boulkroune =20 ________________________________ De : Hemanth Balaji [mailto:bal...@gm...]=20 Envoy=E9 : mardi 26 juin 2007 17:08 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin) Objet : Re: [Sipp-devel] Problem: SIPP + TLS with "-t ln" generates = SSLv2Client Hello =20 Hi Olivier, I have just submitted a patch. Thanks, Hemanth. On 6/26/07, Boulkroune, Olivier (Non-HP:Atos Origin) < = oli...@hp... <mailto:oli...@hp...> > wrote: Hello Hemanth, =20 Thanks for reporting this issue. I don't have the bandwidth to = investigate this now, so feel free to submit a patch if you do. =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de Hemanth = Balaji Envoy=E9 : lundi 25 juin 2007 19:04 =C0 : sip...@li... Objet : [Sipp-devel] Problem: SIPP + TLS with "-t ln" generates = SSLv2Client Hello =20 Hi All, I was using SIPP with TLS and found that when I used SIPP with = multi-socket TLS (-t ln). SIPP sends a SSLv2 client hello instead of a TLSv1 hello and hence the server (not SIPP server) drops = the packet outputting "wrong version number". This problem is=20 not seen with the single socket TLS (-t l1). Moreover in the former = case,only the client hello is sent as SSLv2, all other TLS messages=20 are sent as TLSv1. Is this a known issue and in there a patch for it?=20 Thanks, Hemanth. =20 |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-06-26 06:53:57
|
Hello Hemanth, =20 Thanks for reporting this issue. I don't have the bandwidth to = investigate this now, so feel free to submit a patch if you do. =20 Best regards, =20 Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de Hemanth = Balaji Envoy=E9 : lundi 25 juin 2007 19:04 =C0 : sip...@li... Objet : [Sipp-devel] Problem: SIPP + TLS with "-t ln" generates = SSLv2Client Hello =20 Hi All, I was using SIPP with TLS and found that when I used SIPP with = multi-socket TLS (-t ln). SIPP sends a SSLv2 client hello instead of a TLSv1 hello and hence the server (not SIPP server) drops = the packet outputting "wrong version number". This problem is=20 not seen with the single socket TLS (-t l1). Moreover in the former = case,only the client hello is sent as SSLv2, all other TLS messages=20 are sent as TLSv1. Is this a known issue and in there a patch for it?=20 Thanks, Hemanth. |
From: Hemanth B. <bal...@gm...> - 2007-06-25 17:03:49
|
Hi All, I was using SIPP with TLS and found that when I used SIPP with multi-socket TLS (-t ln). SIPP sends a SSLv2 client hello instead of a TLSv1 hello and hence the server (not SIPP server) drops the packet outputting "wrong version number". This problem is not seen with the single socket TLS (-t l1). Moreover in the former case,only the client hello is sent as SSLv2, all other TLS messages are sent as TLSv1. Is this a known issue and in there a patch for it? Thanks, Hemanth. |
From: Boulkroune, O. (Non-HP:A. Origin) <oli...@hp...> - 2007-06-14 16:47:46
|
What about using both send_timeout and recv_timeout options together ? = Would it not be enough to cover all hanging cases ? =20 Olivier Boulkroune =20 ________________________________ De : Verbeiren, David [mailto:dav...@in...]=20 Envoy=E9 : jeudi 14 juin 2007 17:27 =C0 : Boulkroune, Olivier (Non-HP:Atos Origin); = sip...@li... Objet : RE: [Sipp-devel] [PATCH] Fix forced exit after max num calls = reached +max time to exit option =20 Regarding pressing 'q' twice or using 'Q', you might be right that it = works fine in the latest version. I had the problem with an earlier = version of SIPp (not really old though, around r250) and simply ported = my patch to the latest before sending it. Earlier, for some reason, the = key presses were ignored once in that quitting=3D11 state. That seems to = work ok in the latest version. =20 The quit_time option remains useful though for automated tests in order = to avoid blocking forever since nobody would press 'q'. =20 The reason for which calls were hanging in my real testing (not my = testing of the quit_time option) is unknown but would be interesting to = find out since the standard scenarios should have proper timeout to = cover all cases, I assume. I might get to that at some point but have no = time for it now. =20 Regards, -David =20 ________________________________ From: Boulkroune, Olivier (Non-HP:Atos Origin) = [mailto:oli...@hp...]=20 Sent: 14 June 2007 15:44 To: Verbeiren, David; sip...@li... Subject: RE: [Sipp-devel] [PATCH] Fix forced exit after max num calls = reached +max time to exit option =20 Hello David, =20 Do you have an example where you were not able to force sipp to quit, = even pressing 'q' twice or pressing 'Q' ? I have it working with a = simple use case. For what reasons were the calls hanging ?=20 =20 Thanks and regards, Olivier Boulkroune =20 ________________________________ De : sip...@li... = [mailto:sip...@li...] De la part de = Verbeiren, David Envoy=E9 : jeudi 14 juin 2007 12:35 =C0 : sip...@li... Objet : [Sipp-devel] [PATCH] Fix forced exit after max num calls reached = +max time to exit option =20 Hi, =20 The attached patch fixes a problem I had when trying to automate tests: = some calls were hanging after the specified number of calls had been = reached (-m option) and it was not possible to force exit anymore (even = pressing 'q' multiple times), causing logs not to be flushed, etc. The = fix was a one-liner: "if (quitting > 11) =3D> force exit" becomes "if = (quitting > 10) =3D> force exit". After max calls reached, quitting = becomes 1, pressing 'q' once makes it 11 and previously that would not = be enough to force exit and it wouldn't increase afterwards. I'm not = really sure of what other use cases this could break though. =20 To help with my automated testing, I also introduced a new option to = specify the maximum time to wait for calls to finish. If exceeded, sipp = aborts all remaining calls and exits properly (i.e. flushing logs, = etc.). Example: ./sipp -quit_time 60 ... to wait for max one minute when = quitting (that is when pressing 'q' or when the max number of calls has = been reached). =20 Regards, -David |