[OpenSIPS-Devel] Memory Leak related to db_mysql/sip_trace

[Bogdan-Andrei Iancu]

Hi Chevio,

Just to refresh me on this matter (and to make some light): it is about 
the pkg memory or shm memory? which one is the was you suspect for the leak?

Have you tried to use the memory debugger and to monitor the used memory 
values?

Regards,
Bogdan

Chevio wrote:
> After a lot of debugging and testing....
>
> 1. I bypassed the db and mysql modules, embedded mysql codde into my custom module and the behavior was the same.
>
> 2. I tested my mysql calls against valgrind and passed fine withoug memory leaks.
>
> 3.  I disabled all mysql related modules including my custom modules and did a simple test
>
> setup a script that replies 484 to all invites. Sent 1000 invites.
>
> Result..
>
> the overall system memory goes down, the  memory per process grows up and is not released in a reasonable period of time (24h). 
>
> I tweaked the timers in tm module to see If it was just  keeping transactions memory too long but still see the same problem.
>
> I have tested versions 1.4tls, notls, 1.5notls and the behavior is the same.
>
> Just by starting and stoping opensips I end up with less free memory available.
>
>
> I can't believe I am the only one having this problem. Has anyone noticed the same issue ?
>
> I believe somewhere in the core the memory is not being released. 
>
> Please someone else test and confirm.
>
> Chevio
>
>
>
> В 23:02 -0700 на 15.03.2009 (нд), Chevio написа:
>   
>> I have been doing some tests as I noticed that opensips is eating the
>> system
>> memory.
>>
>>     
> ...
>
> This seems like a problem I've been discussing with Bogdan on irc - from
> what I've seen in the DB layer code and the modules, if you fetch a
> string from the database it's never freed - the memory is allocated in
> the db_row functions, and db_free_row() is never called, except in error
> conditions.
>
> (There's also db_free_rows, which DOES NOT call db_free_row).
>
> Chevio, which memory allocator are you using? I guess the system one,
> judging by the fact that the memory manages to grow so much (the others
> have a limited pool). Can you try enabling the memory allocator
> debugger, running for a while with the mysql-intensive stuff and then
> killing the process and seeing where do the allocations that were left
> were done from?
>
>
>