[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