6 Oct
2011
6 Oct
'11
6:31 p.m.
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:
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
Hello,
On 10/4/11 12:27 PM, Klaus Darilion wrote:
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? 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_th…