[Devel] handle_publish: Bad body format

[Klaus Darilion]

Hi Bogdan!

should I re-test with SVN or 1.2?

Bogdan-Andrei Iancu wrote:
> 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
>>
>