Re: memory corruption on reload

On Mon, Aug 13, 2007 at 05:33:48PM +0100, Chris Wik wrote:
> Jared Mauch wrote:
> >> [root@brick ~]# sysmond: 16:21:28 Done reloading new config file
> >> *** glibc detected *** malloc(): memory corruption: 0x098a05d0 ***
> > 
> > 	Does it leave a core file?
> 
> Not in my cwd, or /tmp, or /usr/local/bin (where sysmond lives). Where
> else would I look? (apologies for my ignorance in this area!)

	So, it would be in the directory you started sysmon from.  Perhaps
named core or core.(some_number)

> > 	What was the configuration change that was made between these two
> > "reloads"?
> 
> Adding new monitors, it happened with various different types of
> monitors, both in the sysmon.conf and inside included config files.

	ok.

> >> After trying to reload sysmond seems to crash and needs to be killed
> >> with signal 9.
> > 
> > 	When this happens, can you use gcore to obtain a core file, or instead
> > use kill -6 (ABORT) to collect the core file so it can be reviewed with gdb?
> > 
> > 	When using gdb, please include the output of the stack trace, you can
> > get this by typing "bt" at the (gdb) prompt.
> 
> OK, next time it happens, I will try this. Right now of course it is
> reloading perfectly :-)
> 
> But I have more configurations to add, so I am sure it will happen again...
> 
> > 	I've had a "beta" version in development for some time, which should
> > also reduce the overall cpu usage of the application.  I'd like to resolve
> > this issue and determine if there is enough interest in a minor feature
> > release.  I know i've been slow in development ;)
> 
> While you're on the topic... One thing I would like is for the uptime
> stats to be non-volatile. At the moment when ever sysmond is restarted
> the uptime stats are reset, it would be nice if they were saved to disk
> somewhere so we could see long term trends, even if sysmond has to be
> restarted for whatever reason. It would also be useful to have
> historical data to back up the SLA's some of our customers have.

	Yeah, this is a work in progress, and a bit of a challenge
just due to the size of the data that we could store.  It may take
quite some time to dump this.  I did just come up with an idea on this
which I will need to test.. hmm.

	- jared

-- 
Jared Mauch  | pgp key available via finger from jared-li9M/[email protected]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.