On Sep 29, 2009 at 09:40, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
It's strange, That's the pkg memory status (memory dump at the end, for debugging).
andrei,
i don't have that kind of debugging on, so why is it trying to dump the memory?
I'll fix that. It should try to print it only if memlog<=debug. Right now it won't print anything if memlog>debug, but it will still iterate on all the memory fragments.
One possibility is that there is a lot to log (e.g. memory leak?) and the syslog daemon slows things down.
this happens only once in a while. perhaps a memory leak would make it happen more often.
It's not the syslog. According to your debug value nothing will be printed to the syslog.
Did you change memlog in the .cfg? What was your debug level?
i don't set memlog in my .cfg file so it is whatever the default value is. debug is 2.
melog is 3 by default, so you won't get anything printed.
Do you have in the log, line containing: "fm_status"? If so could you send me the output of grep "f_malloc.c" logfile ?
there is no such line in syslog.
Does the same happen if you compile with -DDBG_QM_MALLOC and without -DF_MALLOC (qm_malloc might catch a problem sooner)?
i have these:
-DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DF_MALLOC \i'll compile with -DDBG_QM_MALLOC to see if there is any difference. but again, why print memory at shutdown when DBG_QM_MALLOC is not enabled?
It should, if memlog < debug (default it's not). It's a good way to debug possible memleaks on production systems and once fixed it will have no impact when not enabled from the .cfg or sercmd.
Andrei