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:[EMAIL PROTECTED] SIP/2.0.
Via: SIP/2.0/UDP 11.22.33.123:5061;branch=z9hG4bK-7275-39-0.
Max-Forwards: 70.
Contact: sip:[EMAIL PROTECTED]:5061.
To: "klaus"<sip:[EMAIL PROTECTED]>.
From: "klaus"<sip:[EMAIL PROTECTED]>;tag=39.
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]'><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:[EMAIL PROTECTED]>;tag=0847ae4039e784441c60c0ce3b39ea30.8a59.
From: "klaus"<sip:[EMAIL PROTECTED]>;tag=39.
Call-ID: [EMAIL PROTECTED]
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@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
