[Devel] handle_publish: Bad body format

Tue May 15 19:01:50 CEST 2007

Hi Klaus,

thanks for the access to the test machine. I managed to find and fix the 
bug (according to our tests)- it is already applied on SVN trunk. Before 
backporting it to 1.2, I would like to know if it possible for you to 
test it also...let me know if you need the patch or something else...

Thanks and regards,
Bogdan

Bogdan-Andrei Iancu wrote:
> Hi Klaus,
>
> yes, doing debug via debug logs is not all the time the best options. 
> In this case, probably the best way will be to attach with GDB to a 
> running process (after the leak occurred) and inspect the shm memory - 
> but is difficult to do this over email :(
>
> as I guess is not possible to get access to tour test system, could 
> send me a description of how to reproduce your test scenario (sipp 
> scripts & commands, relevant part of scripts). I will ask Anca to 
> reproduce it on our systems....
>
> I really want to solve this till the 1.2.1 release, otherwise I see no 
> option than to delay the release until we figure out the problem.
>
> Regards,
> Bogdan
>
> Klaus Darilion wrote:
>> Hi Bogdan!
>>
>> When running in debug=4 mode, the problem is gone. Maybe the problem 
>> happens only during high traffic, but in debug mode openser is really 
>> slow.
>>
>> regards
>> klaus
>>
>> Bogdan-Andrei Iancu wrote:
>>> Klaus,
>>>
>>> can you get a post the entire log (including all the mem logs from 
>>> runtime) in debug mode? It is important to see in what context the 
>>> transactions were allocated.
>>>
>>> thanks,
>>> bogdan
>>>
>>> Klaus Darilion wrote:
>>>> 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
>