Bugs item #1887999, was opened at 2008-02-06 18:12
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1887999&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver 1.2.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Will Quan (will_quan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: memory leak in canceled call with diversion    header

Initial Comment:
[Scripts attached to reproduce the issue.]

I think the issue is with ACC log_extra setting:
    modparam("acc", "log_extra", "div=$di")

The acc callback 'on_missed' is invoked when the call is canceled (487). With 
this 'log_extra' setting, the acc function extra2strar() executes and parses 
the diversion header in the request. It is this memory that is not freed 
(msg->diversion->parsed).




----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-25 17:12

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Closed - keep 1879864 for reporting.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-11 18:26

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Will,

A fix is available on SVN trunk - please update and test again to see if
the problem was fixed. I need your confirmation before doing a backport
to
1.3 and 1.2

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-07 13:22

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi will,

Fortunately (strange to say this :D) a crash was reported due the same
cause. More or less it confirmed my suppositions on this matter, so things
are clear now.

I will prepare a general solution in TM module.

Regards,
Bogdan 

----------------------------------------------------------------------

Comment By: Will Quan (will_quan)
Date: 2008-02-06 20:38

Message:
Logged In: YES 
user_id=1850067
Originator: YES

Hi bogdan,

No core dump. 
I may have been running slow enough to where the calls were single-handled
on the same process.

I hacked a fix that frees the memory back in acc extra2strar, after the
ACC log is generated. However, I do not have a general solution :(
--will


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-06 19:53

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Will,

I went through the debug output you had in the email - very useful.
Take a look at the following output:

Jan 31 16:12:05 www /openser[64400]: DBG: trans=0x4849523c, callback type
128, id 1 entered
Jan 31 16:12:05 www /openser[64400]: qm_malloc(0x8151120, 212) called from
parser/parse_diversion.c: parse_diversion_header(54)
Jan 31 16:12:05 www /openser[64400]: qm_malloc(0x8151120, 212) returns
address 0x81ab378 frag. 0x81ab360 (size=388) on 1 -th hit
Jan 31 16:12:05 www /openser[64400]: qm_malloc(0x8151120, 24) called from
parser/parse_to.c: parse_to_param(278)
Jan 31 16:12:05 www /openser[64400]: qm_malloc(0x8151120, 24) returns
address 0x81a9788 frag. 0x81a9770 (size=32) on 1 -th hit


>From TM, the callback type 128 is triggered - note this is
TMCB_RESPONSE_OUT and not TMCB_ON_FAILURE as you thought.
The TMCB_RESPONSE_OUT gets as param both the request (in shm mem) and the
reply.
In acc module (which installs the callback) parse the request (from shm)
looking for some hdrs (due pseudo vars). So, the newly parsed header body
exists in private mem (0x81ab378 and 0x81a9788) and it is attached to the
request which resides in shm memory.
This is why the  0x81ab378 and 0x81a9788 chunks are not freed when the
processing of the reply is done - because they are attached to the request,
in shm memory.
The req from shm is freed when the transaction is completed - don't you
get a core dump when this happens - as the chunks from private memory
(potential from other process) are freed as shm memory ?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1887999&group_id=139143

_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel

Reply via email to