Sorry about that; I have not been running it with the latest sipp. I
built that patch against 2.0.1, and have been running my patched 2.0.1
sipp with 400 calls for weeks on end with no crashes. I ported the patch
to 3.0 in a vain attempt to get the patch accepted. My conclusion is that
not many other than myself are using sipp to do longevity testing sending
RTP, or else the RTP questions and patches would get more traction.
I went farther in my sipp patching: in my version you can specify a shared
library as a pcap filter; your filter is called with each packet before
its sent. This allows you to tailor the RTP stream per virtual user;
important for properly testing my application. Unless there is an loud
outcry on this list, with a substantial number of users swearing they do
use the pcap_play interface for anything other than DTMF, and they too
notice the crashes, I can't see spending the time to productize either of
these patches.
Regards, and good luck,
Ken
On Fri, 11 Sep 2009 05:43:59 -0400, catalina oancea
<catalina.oan...@gmail.com> wrote:
> Hi, thanks for answering.
>
> Have you tried your patch on the latest version of sipp, and 200
> simultaneous calls? I applied it (I had to do it manually) and
> compiled, then I ran sipp with 20 calls per second and maximum
> simultaneous calls = 200, and after it reaches 900-1000 completed
> calls it crashes. (the same thing happened with my patch, that's why I
> knew it's not good)
>
> Here is the core dump:
>
>
> Core was generated by `./sipp -sf
> /root/sipp.trimite_14.14/client_scen.xml -t un -r 20 -l 200 -aa -i 1'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x000000000042bcd4 in call::get_remote_media_addr (this=0x295e510,
> msg=0x7fff70fd3e40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 192.168.13.13:7169;branch=z9hG4bK-9914-736-8\r\nRecord-Route:
> <sip:192.168.14.14;lr=on;ftag=736;did=984.bbbc24d4>\r\nFrom: 0003*020
> <sip:0003*...@192.168.14.14:5060>;tag=7"...) at call.cpp:249
> 249 (_RCAST(struct sockaddr_in *,
> &(play_args_a->to)))->sin_family = AF_INET;
> (gdb) bt full
> #0 0x000000000042bcd4 in call::get_remote_media_addr (this=0x295e510,
> msg=0x7fff70fd3e40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 192.168.13.13:7169;branch=z9hG4bK-9914-736-8\r\nRecord-Route:
> <sip:192.168.14.14;lr=on;ftag=736;did=984.bbbc24d4>\r\nFrom: 0003*020
> <sip:0003*...@192.168.14.14:5060>;tag=7"...) at call.cpp:249
> ip_media = 235841728
> video_port = 15936
> audio_port = 7706
> #1 0x000000000042c41d in call::process_incoming (this=0x295e510,
> msg=0x7fff70fd3e40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 192.168.13.13:7169;branch=z9hG4bK-9914-736-8\r\nRecord-Route:
> <sip:192.168.14.14;lr=on;ftag=736;did=984.bbbc24d4>\r\nFrom: 0003*020
> <sip:0003*...@192.168.14.14:5060>;tag=7"..., src=0x7fff70fe3e40) at
> call.cpp:2994
> reply_code = 200
> responsecseqmethod =
> "\000Á\200\000\000\000\000\000\000Á\200\000\000\000\000\000\bÁ\200\000\000\000\000\000\220¡\204\002\000\000\000\000
> <ýpÿ\177\000\000ñ\215E\000\000\000\000\000ð<ýpÿ\177\000\000Ð<ýpÿ\177\000\000\020"
> txn =
> "\000\000\000\000\000\000\000\000ÿ0\204p6\000\000\000À:ýpÿ\177\000\000c\227F\000\000\000\000\000à5ýpÿ\177\000\000ØA\214\002+\000\000\000\000\000\000\000ÿ\177\000\000\f\000\000\000\000\000\000\0000<ýpÿ\177\000\000
> BG\000\000\000\000\000\020;ýpÿ\177\000\000c\227F", '\0' <repeats 13
> times>,
> "\2309ýpÿ\177\000\000\000\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿJBG\000\000\000\000\000
> BG", '\0' <repeats 13 times>,
> "È9ýpÿ\177\000\000\000\000\000\000\006\000\000\000k", '\0' <repeats 11
> times>, "\n", '\0' <repeats 43 times>, "0x 34)", '\0' <repeats 21
> times>...
> cookie = 3983404949594954913
> ptr = 0x40f64f
> "ÉÃ\220UH\211åH\203ì0H\211}èH\211uàH\211UØH\213UàH\213EèH\211ÑH)ÁH\211ÈHÁø\003H\211EøH\213EøH\215\fÅ"
> search_index = 43378448
> found = false
> actionResult = 8291392
> test = 0
> request = "BYE", '\0' <repeats 61 times>
> __PRETTY_FUNCTION__ = "virtual bool
> call::process_incoming(char*, sockaddr_storage*)"
> #2 0x000000000043729b in process_message (socket=0x295fab0,
> msg=0x7fff70fd3e40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 192.168.13.13:7169;branch=z9hG4bK-9914-736-8\r\nRecord-Route:
> <sip:192.168.14.14;lr=on;ftag=736;did=984.bbbc24d4>\r\nFrom: 0003*020
> <sip:0003*...@192.168.14.14:5060>;tag=7"..., msg_size=786,
> src=0x7fff70fe3e40) at sipp.cpp:3136
> call_id = 0x7e8440 "736-9...@192.168.13.13"
> listener_ptr = (class listener *) 0x295e710
> #3 0x000000000043aeff in pollset_process (wait=0) at sipp.cpp:3276
> msg = "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 192.168.13.13:7169;branch=z9hG4bK-9914-736-8\r\nRecord-Route:
> <sip:192.168.14.14;lr=on;ftag=736;did=984.bbbc24d4>\r\nFrom: 0003*020
> <sip:0003*...@192.168.14.14:5060>;tag=7"...
> src = {ss_family = 2, __ss_align = 0,
> __ss_padding =
> "Ð>þp\026\000\000\000`E\200\002\000\000\000\000\200>þpÿ\177\000\000\210>þpÿ\177\000\000
>> þpÿ\177\000\000ýùc\000\000\000\000\000\...@\177\000\000\000\000\000\220@\177",
> '\0' <repeats 13 times>,
> "\002\000\000\000\000\000\000\000à>þpÿ\177\000\0005úC\000\000\000\000\000\000>þpÿ\177\000\000ÔòC\000\000\000\000"}
> len = 786
> rs = 0
> loops = 1000
> read_index = 52
> __PRETTY_FUNCTION__ = "void pollset_process(int)"
> #4 0x000000000043b3f6 in traffic_thread () at sipp.cpp:3432
> running_tasks = (task_list *) 0x7f4090
> loops = 999
> last = (class task *) 0x2804560
> iter = {_M_node = 0x7f4090}
> L_file_name =
> "/root/sipp.trimite_14.14/client_scen_9914_screen.log\000+\000\000¾\...@\000\000\000\000\000\220?þpÿ\177\000\000
> ù´p6\000\000\000H\001", '\0' <repeats 14 times>, "`Hþpÿ\177", '\0'
> <repeats 18 times>,
> "2\207p6\000\000\000\...@þpÿ\177\000\000ð?þpÿ\177\000\000\000\000\000\000\000\000\000\000\227\030c\000\000\000\000\000à?þpÿ\177\000\000x@þpÿ\177\000\000
> @þpÿ\177\000\000\000\000\000\000\000\000\000\000H\001\000\000\000\000\000\000p\001\000\000\000\000\000\000\030\000\000\000"...
> #5 0x000000000043eae4 in main (argc=27, argv=0x7fff70fe4868) at
> sipp.cpp:5039
> argi = 27
> media_sockaddr = {ss_family = 2, __ss_align = 0,
> __ss_padding =
> "\n\000\000\000\000\000\000\000\026\000\000\000\000\000\000\000.n=ö\000\000\000\0004\...@p6",
> '\0' <repeats 11 times>,
> "ÐEþpÿ\177\000\000.N=ö\000\000\000\000`Gþpÿ\177\000\000xGþpÿ\177\000\000x:\200p6\000\000\000
> fþpÿ\177\000\000¨À\200\000\000\000\000\000\020\004\000\000\000\000\000\...@\004\000\000\000\000\000"}
> pthread2_id = 4252115
> pthread3_id = 140735089100400
> L_maxSocketPresent = 0
> generic_count = 0
> slave_masterSet = false
> __PRETTY_FUNCTION__ = "int main(int, char**)"
>
>
>
> 2009/9/10 Kenneth Cox <kens...@gmail.com>:
>> I filed a patch for this same issue in 2008. Sadly it appears unwanted.
>> You are right about the lack of thread safety in the memory management
>> of
>> play_args. My patch is here:
>>
>> https://sourceforge.net/tracker/?func=detail&aid=1885530&group_id=104305&atid=637566
>>
>> Ken
>>
>> On Thu, 10 Sep 2009 05:40:25 -0400, catalina oancea
>> <catalina.oan...@gmail.com> wrote:
>>
>>> Hello again,
>>>
>>>
>>> I am sorry to write so late, unfortunately I didn't have time to do
>>> more debugging and try to find the cause this bug. But I finally got
>>> to it and here is my idea.
>>>
>>> I started adding debugs in the send_packets function, for example I
>>> printed the destination IP taken from the function argument
>>> (play_args's to member). Normally my prints showed the correct IP
>>> address. But each time the error occurred, the destination IP for
>>> instance had values such as 0.0.0.0 or similar. I realized that
>>> probably play_args is modified somewhere else by some other thread.
>>> But I also printed its value in the send_wrapper function (in
>>> call.cpp) and there the prints always showed a correct value.
>>> So I changed the send_packets to use an argument passed by value
>>> instead of by reference. I changed it from this:
>>> send_packets (play_args_t * play_args)
>>> to this
>>> send_packets (play_args_t play_args)
>>>
>>> also changing some lines that needed to be changed for this.
>>>
>>> I am not an experienced programmer and my solution might not be the
>>> best one. Passing thus struct variable by value might affect
>>> performance. Also, the pcap member of the structure is a pointer so
>>> the address value will be copied so if it gets changed in the
>>> meanwhile the change will still affect its content.
>>>
>>> I tested sipp after the change and the rtp packages still seem
>>> correct. And the error no longer occurs. I attach my patch.
>>>
>>>
>>> Best regards,
>>>
>>> Catalina
>>>
>>>
>>>
>>> 2009/4/16 Dmitry Goncharov <dgoncha...@unison.com>:
>>>>
>>>>
>>>> catalina oancea wrote:
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the idea.
>>>>
>>>> What I see using strace is that normal sendto looks like this:
>>>>
>>>> sendto(14,
>>>> "\...@$&\0\264>z\200\0\31\345\0'\273T\21S3\17vvswwvwsvy}\376"...,
>>>> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
>>>> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
>>>> sendto(14,
>>>>
>>>> "\...@$&\0\264-Q\200\0\31\346\0'\273\364\21S3\17~\177\374\375\375\376\376\374\371\367\372\366"...,
>>>> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
>>>> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
>>>> sendto(14,
>>>>
>>>> "\...@$&\0\264\26=\200\0\31\347\0'\274\224\21S3\17\177}\177\375\374\376\376\372\374\177\375\373"...,
>>>> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
>>>> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
>>>> sendto(14,
>>>> "\...@$&\0\264\263\35\200\0\31\350\0'\2754\21S3\17qxyvtvy~}x~|"...,
>>>> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
>>>> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
>>>> sendto(14,
>>>>
>>>> "\...@$&\0\264?\347\200\0\31\351\0'\275\324\21S3\17\364\364\365\371\370\365\364\363\363\365\371\367"...,
>>>> 180, MSG_DONTWAIT, {sa_family=AF_INET, sin_port=htons(9764),
>>>> sin_addr=inet_addr("192.168.12.12")}, 16) = 180
>>>>
>>>>
>>>> And the one that causes the error looks like this:
>>>>
>>>> sendto(14,
>>>>
>>>> "\...@$&\0\264T\234\200\0\31\352\0'\276t\21S3\17xyuy}\377\374\367\373\376\372\373"...,
>>>> 180, MSG_DONTWAIT, {sa_family=0x2e32 /* AF_??? */,
>>>> sa_data="168.13.13\r\nCSe"}, 16) = -1 EAFNOSUPPORT (Address family not
>>>> supported by protocol)
>>>>
>>>> Is this a bug in the way the parameters are sent?
>>>>
>>>>
>>>>
>>>>
>>>> To me this looks like a bug (assuming you properly compiled and linked
>>>> sipp). Why don't you add some logging around the failing syscall and
>>>> figure
>>>> out what went wrong?
>>>> BR, Dmitry
>>>>
>>>>
>>>>
>>>> You can run sipp under strace and find out which particular syscall
>>>> fails.
>>>> Just run strace -ff -o strace.log sipp ...
>>>> Where ... should be replaced with sipp args.
>>>> Then read and analyze the strace log files.
>>>>
>>>>
>>>> I would also try to increase the number of open file descriptors per
>>>> process. Like this ulimit -n <some big number>.
>>>>
>>>> HTH, Dmitry
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
