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
