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/
>
------------------------------------------------------------------------------
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
