[SR-Users] Memory Leak on DB Errors?

Klaus Darilion klaus.mailinglists at pernau.at
Thu Oct 6 17:31:31 CEST 2011


Indeed, DBG_QM_MALLOC is defined. So I have set memlog=1 and dumped 
mem_info with:
sercmd cfg.set_now_int core mem_dump_pkg 13286
sercmd cfg.set_now_int core mem_dump_shm 13286

The dumps were done after ~1h uptime. I can not offload the traffic and 
wait until transactions are freed, thus the logs are quite huge (~15MByte)

http://pernau.at/kd/memlog.zip

I have no idea for what I should look for - any hints how to analyze the 
mem_dump?

Thanks
Klaus


On 06.10.2011 13:07, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 10/5/11 11:18 AM, Klaus Darilion wrote:
>>
>>
>> On 04.10.2011 14:03, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> On 10/4/11 12:27 PM, Klaus Darilion wrote:
>>>> Meanwhile the server was restarted and the DB problems were fixed. As
>>>> it is a production server I can not reproduce anymore.
>>>
>>> So, once it started it didn't recovered, continued always with that
>>> error? How much of shm did you configure?
>>>
>>> You can try to attach from time to time to one process (can be even the
>>> main one to avoid blocking a sip worker) and walk through the shm
>>> allocated chunks, in order to see if there are some unexpected
>>> repetitions of allocation from same place in sources.
>>>
>>> I posted the gdb script for walking through pkg at some point, the
>>> difference will be to start from the head of shm list (i.e., starting
>>> with shm_block->first_frag instead of mem_block->first_frag):
>>>
>>> http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory#walking_through_pkg_with_gdb
>>>
>>
>> Hi Daniel!
>>
>> After reading this wiki page I came to the conclusion that for further
>> debugging I have to recompile Kamailio (using DBG_QM_MALLOC memory
>> manager instead of F_MALLOC). With the default memory manager it is
>> not possible to debug the problem. Is it correct?
> in 3.1 malloc debug was left on (with the goal of catching buffer
> overflows quickly after several years of development of no using this
> flag in production), so unless you switched if off, you should get the
> reports. you can check in the output of kamailio -V
>
> Cheers,
> Daniel
>



More information about the sr-users mailing list