[Home]

Summary:ASTERISK-06293: [patch] chan_h323 memory leak
Reporter:aymeric (aymeric)Labels:
Date Opened:2006-02-12 09:39:36.000-0600Date Closed:2006-08-25 11:47:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_h323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) all_changes.18552.patch
Description:I'm testing the NuFone H323 channel driver "mass calling" with callgen323.
I use Open H.323 version v1.17.1 and PWLib v1.9.0 as stated in README file and the following extension:
exten => _X.,1,Answer
exten => _X.,2,Wait(1)
exten => _X.,n,Playback(demo-thanks)
exten => _X.,n,Hangup

Asterisk get bigger and bigger in memory as the number of calls received rise.

Compiled Asterisk with MALLOC_DEBUG and after one only call, I get

*CLI> show memory allocations chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
      128 bytes allocated in          oh323_alloc at line   823 of chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
      392 bytes allocated in           build_peer at line  1962 of chan_h323.c
       36 bytes allocated in  external_rtp_create at line  1146 of chan_h323.c
       36 bytes allocated in  external_rtp_create at line  1146 of chan_h323.c
2944 bytes allocated 10 units total

"36 bytes allocated in  external_rtp_create at line  1146 of chan_h323.c"
relative to the following source code in ast_h323.cpp:

info = on_external_rtp_create(connection.GetCallReference(), (const char *)connection.GetCallToken());
if (!info) {
cout << "\tERROR: on_external_rtp_create failure" << endl;
return;
} else {
...
free(info);

Seems to be clean.

Why do Asterisk tell me that "external_rtp_create" haven't been freed ? (I just start working with Asterisk).

Using the following patch, I "correct" the exteranl_rtp_create" allocation and Asterisk grow slower in memory.
I applied patch 0006446 before making changes.
Comments:By: Tilghman Lesher (tilghman) 2006-03-10 23:40:21.000-0600

We need a disclaimer on file with Digium before we can look at your patch.
By: Andrey S Pankov (casper) 2006-04-10 14:13:42

Do you have a disclaimer on file with Digium?
By: Serge Vecher (serge-v) 2006-04-10 15:07:41

most of all_changes.patch seem to be a combination of patch.listbugofg++ and chan_h323.diff from bug 6446 (now committed), with addition of the code snippet in Description. Perhaps the 3-liner fix does not require a disclaimer.
By: Andrey S Pankov (casper) 2006-04-10 15:10:40

Anyway there should be a clean patch for the most recent code.
By: brett (celtic6969) 2006-04-17 08:20:22

Hello,

Not sure if my issue is related, but I have also found a memory leak when using H323 channel drivers. I recently depolyed asterisk 1.2.7.1 in a large scale H323 environment and constantly need to reboot the server to free memory. I have found the memory decreasing using the 'top' application and asterisk being the process consuming all the memory. I have seen the same issue with two differnt drivers:
ooh323c-0.4 (asterisk-addons 1.2.2)
oh323-0.7.3 (InAccess Networks)
pwlib: v1.8.7/Mimas_patch2
openh323: v1.15.6/Mimas_patch2

Testing was done with callgen323.
This is quite critical for our deployment, so please let me know if there is any other info I can provide which will expedite the resolution.
By: Andrey S Pankov (casper) 2006-04-17 10:42:39

For oh323 driver please contact InAccess.
For ooh323c - objsys.
For chan_h323 - it seems like nobody interested in it, even NuFone.
If you want smth to work with asterisk please use sip or iax2.
And H323 consultant will not work for free.
By: aymeric (aymeric) 2006-04-17 10:49:42

Got a disclaimer on file with Digium and got some more patch relative to chan_h323 memory consuption to submit.


By: Andrey S Pankov (casper) 2006-04-17 11:07:15

That's great. Please upload clean patches for svn trunk and specify exact revisions.
By: jerjer (jerjer) 2006-04-17 11:35:47

Nobody has provided any valid debug to work from.   As I have made very clear we no longer utilize H.323, thus need proper motivation to spend time on something we no longer utilize in our own operations.
By: brett (celtic6969) 2006-04-17 11:47:46

Appreciate the prompt reply.

I understand the protocol of choice is SIP, however it makes it difficult for me to promote Asterisk / Digium as a solution when 80% of clients are still using h323 Cisco gateways. For the interim I need to be "compatible" with h323 clients until they have migrated their business to SIP. If I need help with h323 what is the preferred channel driver (I'm assuming ooh323 due to it's inclusion in addons) and how much will it cost for a consultant to assist ? Does Digium offer any type of maintenance support / contracts for h323 with * business addition ?

TIA
By: Andrey S Pankov (casper) 2006-04-17 13:24:34

> 80% of clients are still using h323 Cisco gateways
There are not lots of only-h323 cisco gateways, just specify
"session protocol sipv2" on a dial-peer or upgrade firmware
to a sip version.

> For the interim I need to be "compatible" with h323
There are lots of h323-sip converters

> I'm assuming ooh323
Does it work, even if included in addons? :)

> how much will it cost for a consultant to assist
Ask a consultant... ;) This not for the bugtracker.
Try to ask on a mailing list...
By: aymeric (aymeric) 2006-04-17 17:58:25

A cleaner patch on version 18552 to correct 2 features:

First part for allocating memory for rtp_info in ast_h323.cpp.
Second, to avoid allocating memory for a call token that have already been allocated in OnReceivedSignalSetup. (incoming call to asterisk)
>>>
if (callid == 0) ..
>>>
callid == 0 to allocate memory for a new call token if the call it's an outgoing call from asterisk.
By: Serge Vecher (serge-v) 2006-05-04 12:38:55

aymetric: are you able to produce any debugging information as requested by JerJer to show that your patch does the right thing, i.e. memory usage for a given period of time with and without the patch?

Thanks!

P.S. Please keep discussion related to the bug only. There are other channels for for OT material.


By: Andrey S Pankov (casper) 2006-05-30 13:54:54

IMO any debugging information is not needed here. If anybody wants to
review the patch it could be done without it. Sorry for "OT material"... ;)
By: Serge Vecher (serge-v) 2006-07-07 15:11:27

casper: do you want to test the patch?
By: Paul Cadach (pcadach) 2006-08-15 11:26:02

I don't see any critical changes in all_changes.18552.patch.  Aymeric, could you explain WHAT do you want to change?
1) Moving allocation of rtp_info structure from chan_h323.c to ast_h323.cpp isn't plays much role because malloc() and free() declared in standard libraries.
2) Why call token with callid equal to 0 should not been allocated? It is updated in h323_make_call()... - Ok, found - It is just replaced by a value prepared at C++ part.


By: Paul Cadach (pcadach) 2006-08-15 13:37:07

As I understand the problem is because rtp_info structure allocated under astmm control while free'd without and free'd memory isn't counted.

Solution: Don't use MALLOC_DEBUG together with chan_h323....
By: Paul Cadach (pcadach) 2006-08-25 11:35:52

As pointed at ~0050354, 1) is not required, 2) is confirmed and fixed in chan_h323-live.


By: Serge Vecher (serge-v) 2006-08-25 11:47:18

no response from Ayumeric and patch is superceded by code in branch in bug 7705. If anybody feels there are any outstanding issues from this bug report that still need to be addressed, please make a respective note in 7705. Thanks!