Hi Max, I found something related to this - actually the crash happened because the Content-len hdr was missing too.
There is a fix on SVN (rev 7030 / 7031) on trunk / 1.6 - please update and test again to see if the crash still occurs or not. Regards, Bogdan Max Mühlbronner wrote: > Yes, exactly. The other carrier/switch was sending a 183 without SDP > body. And at least it seemed like our Server threw a coredump whenever > it was received, after omitting rtpproxy for this carrier (no > rtpproxy_offer / nathelper) it works fine --> no crash. > > I will try to send you some Siptrace if i still got access to it. > > > Thanks > > Max M. > > Bogdan-Andrei Iancu schrieb: > >> Hi Max, >> >> What you mean by "a missing SDP in the progress " ? you mean a 183 >> without SDP ? so a force_rtp_proxy on something without SDP may lead in >> crash? >> >> Regards, >> Bogdan >> >> >> Max Mühlbronner wrote: >> >> >>> Hello, >>> >>> Very sorry for my late reply, i am not fully online at the moment. >>> >>> Although in the meantime we did figure out the crashes were not related >>> to the contact address (my first impression) but the reason was >>> a missing SDP in the progress from the other carrier. We fixed it >>> temporarily by omitting rtpproxy for this carrier. --> No more Crashing. >>> >>> I will try to find a solution for sending you the coredump as soon as >>> possible. >>> >>> Thanks >>> >>> Max M. >>> >>> Bogdan-Andrei Iancu schrieb: >>> >>> >>> >>>> Hi Max, >>>> >>>> it will have me a lot if I could get access to the corefile for >>>> inspection.....do you think is possible ? we are planning a new release >>>> on 1.6 branch for next week and I really want to have this fixed. >>>> >>>> Regards, >>>> Bogdan >>>> >>>> Max Mühlbronner wrote: >>>> >>>> >>>> >>>> >>>>> Hello Bogdan, >>>>> >>>>> too bad, but the problem continues after update. >>>>> >>>>> opensips-dev:/tmp/opensips# gdb /sbin/opensips core.opensips.sig11.9272 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> <http://gnu.org/licenses/gpl.html> >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "i486-linux-gnu"... >>>>> Cannot access memory at address 0xb7f93658 >>>>> (gdb) bt >>>>> #0 0x080ec894 in get_all_bodies (msg=Cannot access memory at address >>>>> 0xbfd928a0 >>>>> ) at parser/parse_multipart.c:197 >>>>> Cannot access memory at address 0xbfd9289c >>>>> >>>>> >>>>> >>>>> svnrevision: 2:6982M >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Max M. >>>>> >>>>> >>>>> Bogdan-Andrei Iancu schrieb: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hi Max, >>>>>> >>>>>> yes, that's the last revision on 1.6 branch - just let me know if the >>>>>> bug is sill there with this version. >>>>>> >>>>>> Thanks and regards, >>>>>> Bogdan >>>>>> >>>>>> Max Mühlbronner wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for the hint. But I really dont understand how this happened >>>>>>> because i thought i did initially check out the 1.6 branch via svn!? >>>>>>> (and not 1.5) But maybe i mixed up something.. >>>>>>> >>>>>>> /usr/src/OPENSIPS-SVN/opensips_1_6 >>>>>>> >>>>>>> i have updated the same 1.6 on another test-system and it seems to be >>>>>>> revision 6982. Would this be sufficient for testing again? >>>>>>> >>>>>>> Br >>>>>>> >>>>>>> Max M. >>>>>>> >>>>>>> Bogdan-Andrei Iancu schrieb: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> 6732 is a revision on 1.5 branch from March 2010 - try to first update >>>>>>>> from SVN branch 1.6 - let me know if the problem is still there or not. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bogdan >>>>>>>> >>>>>>>> Max Mühlbronner wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Sorry for the late reply, i had very limited access to my mail last >>>>>>>>> week. >>>>>>>>> >>>>>>>>> version: opensips 1.6.2-notls (i386/linux) >>>>>>>>> flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, >>>>>>>>> SHM_MEM, >>>>>>>>> SHM_MMA >>>>>>>>> >>>>>>>>> P, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>>>>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>>>>>>>> MAX_URI_SI >>>>>>>>> >>>>>>>>> ZE 1024, BUF_SIZE 65535 >>>>>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>>>>>>>> svnrevision: 2:6732M >>>>>>>>> @(#) $Id: main.c 6169 2009-09-22 12:48:37Z bogdan_iancu $ >>>>>>>>> main.c compiled on 10:35:28 Mar 23 2010 with gcc 4.3.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Max M. >>>>>>>>> >>>>>>>>> Bogdan-Andrei Iancu schrieb: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> Any chance to get my hands on that core file (on your server) or >>>>>>>>>> should >>>>>>>>>> we try some remote debugging ? >>>>>>>>>> >>>>>>>>>> Also, what is the revision number (see with opensips -V ) >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Bogdan >>>>>>>>>> >>>>>>>>>> Max Mühlbronner wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> yes, it is reproducible for me. 1.6.2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best Regards >>>>>>>>>>> >>>>>>>>>>> Max M. >>>>>>>>>>> >>>>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>>>> Von: [email protected] >>>>>>>>>>> [mailto:[email protected]] Im Auftrag von >>>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>>> Gesendet: Dienstag, 15. Juni 2010 18:31 >>>>>>>>>>> An: OpenSIPS users mailling list >>>>>>>>>>> Betreff: Re: [OpenSIPS-Users] force_rtp_proxy /rtpproxy_offer - >>>>>>>>>>> Opensips >>>>>>>>>>> coredump on call without userinfo in contact address ? >>>>>>>>>>> >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> What version of opensips are you using ? I was trying to search for >>>>>>>>>>> the >>>>>>>>>>> file and line mentioned by your gdb printout, but I cannot >>>>>>>>>>> correlate. >>>>>>>>>>> >>>>>>>>>>> Also, is this bug reproducible by you? As I'm not 100% sure it is >>>>>>>>>>> Contact related as the backtrace shows the crash when trying to get >>>>>>>>>>> the >>>>>>>>>>> body(s) of the reply. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Bogdan >>>>>>>>>>> >>>>>>>>>>> Max Mühlbronner wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hello everyone, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I have a small problem with opensips 1.6.2 trunk version (updated >>>>>>>>>>>> via >>>>>>>>>>>> svn few days ago, still same issue.) >>>>>>>>>>>> I can see the call setup from Opensips to the carrier (using >>>>>>>>>>>> rtpproxy) >>>>>>>>>>>> which is fine, up to some point: Invite, Progress, Ringing --> OK >>>>>>>>>>>> >>>>>>>>>>>> All other calls are fine, I did not notice any difference with >>>>>>>>>>>> this >>>>>>>>>>>> carrier, but now i realized the contact address of the OK for >>>>>>>>>>>> these >>>>>>>>>>>> calls contains no userinfo/ @character. >>>>>>>>>>>> >>>>>>>>>>>> Server: Sippy. >>>>>>>>>>>> Contact: Anonymous <sip:195.24.34.24:5061>. >>>>>>>>>>>> >>>>>>>>>>>> On a call setup i can reproduce a coredump on every call like >>>>>>>>>>>> this. So i >>>>>>>>>>>> did some research, but according to RFC2396 (Uniform Resource >>>>>>>>>>>> Identifiers - URI) and also other sources, a uri can consist of >>>>>>>>>>>> just an >>>>>>>>>>>> ip adress/port combination without any userinfo@ part. But if i >>>>>>>>>>>> receive >>>>>>>>>>>> a call in this way, my opensips instance will crash immediately? >>>>>>>>>>>> (But it >>>>>>>>>>>> is probably more related to the nathelper module /force_rtp_proxy >>>>>>>>>>>> then >>>>>>>>>>>> opensips?) >>>>>>>>>>>> >>>>>>>>>>>> Any ideas, suggestions are really appreciated. Thanks very much in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 20 - 24 September 2010, Frankfurt, Germany www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
