[asterisk-dev] Query on Memory Management Guidelines

[Grey Man]

Russell Bryant wrote:

>>Grey Man wrote:
>> One test I did on my patch was to turn on the MALLOC_DEBUG flag and use "show memory summary app_dial.c" before and after >> a call. In doing so I was seeing an increase per call of approx. 64 bytes. As best as I could tell (and I could be very wrong so please >> excuse me if so) the problem was not down to my modifications but to line 1593 in app_dial.c:

> Another thing you can do is compare the output of "show memory
> allocations app_dial.c" before and after the call.  If there is a leak
> in there, you should see an additional entry that was not there before.
 > It will point you to the line number where the allocation was made.
>
> It may not have been your fault.  :)

It was my fault so no suprises there, I was passing the wrong parameter to ast_free.

I've got my mechanism working now and the memory allocations in app_dial.c are going back to 0 after a call. However I just wanted to sanity check my approach to make sure I am not doing something foolish.

Pseudo Code:

1. Call is answered in app_dial.c and I allocate a new memory structure using:
     struct x * mydata;
    mydata = ast_malloc(sizeof(*mydata));

2. Using ast_sched I add a new entry with a custom callback function and pass in mydata as the data parameter,

3. I create a new thread to process my ast_sched context while the main app_dial thread gets on with bridging the call,

4. My callback function gets periodically called and modifies some properties of the mydata struct which are used by the original thread that is bridging the call,

5. Once the call hangs up if the entry added to the ast_sched context in step 2 is in the list it is removed and mydata is deallocated using:
  ast_free(mydata);

6. If the call is hungup and the ast_sched entry added in step 2 is not in the list it means the callback function was in the middle of a call when the hangup occurred. In that case I set a hungup property on mydata, wait for the callback function to finish and then deallocate the memory on the callback thread which was the one created in step 3. This lets the original thread in app_dial continue as normal and the result from the callback thread is irrelevant and ignored.

I've tested this approach out and it seems to be fine. The only thing which I'm a bit wary of is allocating memory on one thread and deallocating on another.

Thanks,

Greyman.







      Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html