[Devel] handle_publish: Bad body format

Klaus Darilion klaus.mailinglists at pernau.at
Fri May 11 15:43:10 CEST 2007


Maybe this is memory related too?

I've made a memdump (after 20 minutes idle) of this strange situation.

is02:/home/klaus3000# openserctl fifo ps
200 OK
Process::  ID=0 PID=6700 Type=attendant
Process::  ID=1 PID=6705 Type=receiver child=0 sock= 1.2.3.4:6060
Process::  ID=2 PID=6708 Type=timer
Process::  ID=3 PID=6710 Type=tcp receiver
Process::  ID=4 PID=6712 Type=tcp main process


http://pernau.at/kd/openser/otherPCmemleak-sigusr1.openser-SVN.log

regards
klaus

Klaus Darilion wrote:
> Hi!
> 
> I've tried with todays SVN 1.2. In the beginning was everything fine - 
> but suddenly after ~150000 messages presence module reports:
> 
> May 11 15:14:00 is02 /usr/sbin/openser[6705]: PRESENCE: generate_ETag: 
> etag= a.1178878809.6705.311731 / 24
> May 11 15:14:00 is02 /usr/sbin/openser[6705]: PRESENCE: handle_publish: 
> Bad body format
> May 11 15:14:00 is02 /usr/sbin/openser[6705]: PRESENCE: handle_publish: 
> ERROR occured
> 
> Following is the PUBLISH - which is generated by SIPP. Any hints?
> 
> U 11.22.33.123:5061 -> 11.22.33.123:6060
> PUBLISH sip:klaus at pernau.at SIP/2.0.
> Via: SIP/2.0/UDP 11.22.33.123:5061;branch=z9hG4bK-7275-39-0.
> Max-Forwards: 70.
> Contact: sip:ua1 at 11.22.33.123:5061.
> To: "klaus"<sip:klaus at pernau.at>.
> From: "klaus"<sip:klaus at pernau.at>;tag=39.
> Call-ID: 39-7275 at 11.22.33.123.
> CSeq: 1 PUBLISH.
> Expires: 60.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, 
> SUBSCRIBE, INFO.
> Content-Type: application/pidf+xml.
> User-Agent: sipp.
> Event: presence.
> Content-Length:  420.
> .
> <?xml version='1.0' encoding='UTF-8'?><presence 
> xmlns='urn:ietf:params:xml:ns:pidf' 
> xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' 
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' 
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' 
> entity='sip:klaus at pernau.at'><tuple 
> id='t532d494f'><status><basic>open</basic></status></tuple><dm:person 
> id='p98169736'><rpid:activities><rpid:unknown/></rpid:activities></dm:person></presence>. 
> 
> 
> #
> U 11.22.33.123:6060 -> 11.22.33.123:5061
> SIP/2.0 415 Unsupported media type.
> Via: SIP/2.0/UDP 11.22.33.123:5061;branch=z9hG4bK-7275-39-0.
> To: "klaus"<sip:klaus at pernau.at>;tag=0847ae4039e784441c60c0ce3b39ea30.8a59.
> From: "klaus"<sip:klaus at pernau.at>;tag=39.
> Call-ID: 39-7275 at 11.22.33.123.
> CSeq: 1 PUBLISH.
> Server: OpenSER (1.2.0-tls (i386/linux)).
> Content-Length: 0.
> .
> 
> 
> 
> 
> 
> 
> 
> 
> Bogdan-Andrei Iancu wrote:
>> Klaus,
>>
>> I'm not 100% sure if the mem leak can be just avoided only with 
>> t_release(). Theoretically, it should ; but practically, there is a 
>> difference between practice and theory :D....
>> Just be sure, try to get the SVN version of 1.2 and run the tests on 
>> it. This way we can be 100% sure !
>>
>> regards,
>> bogdan
>>
>> Klaus Darilion wrote:
>>>
>>>
>>> Bogdan-Andrei Iancu wrote:
>>>> Hi Klaus,
>>>>
>>>> the fix was also backported to 1.2.
>>>
>>> Uups. I'missed that. But i still use my old binaries with 
>>> t_release(). This should be fine too - isn't it?
>>>
>>> regards
>>> klaus
>>>
>>>>
>>>> regards,
>>>> bogdan
>>>>
>>>> Klaus Darilion wrote:
>>>>>
>>>>>
>>>>> Juha Heinanen wrote:
>>>>>> Klaus Darilion writes:
>>>>>>
>>>>>>  > I still use openser 1.2, thus I have to use t_release()
>>>>>>
>>>>>> i have missed this: how do 1.2 and trunk differ regarding t_release?
>>>>>
>>>>> With openser 1.2, if you use t_newtran() before handle_publish() 
>>>>> you have to explicitely free the transaction with t_release().
>>>>>
>>>>> In trunk it is fixed and the transaction gets freed also if you 
>>>>> omit t_release().
>>>>>
>>>>> regards
>>>>> klaus
>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>>>
>>>>
>>>
>>
> 
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel



More information about the Devel mailing list