[Linux-ha-dev] Info: CRM Memory Leaks
Andrew Beekhof
beekhof at gmail.com
Sun Feb 11 02:34:39 MST 2007
On 2/10/07, Lars Marowsky-Bree <lmb at suse.de> wrote:
> On 2007-02-09T16:43:50, Andrew Beekhof <abeekhof at suse.de> wrote:
>
> Wow, Andrew, thanks for the work here and fixing all of this!
>
> > == NEVER AGAIN ==
> >
> > The embarrassment of such a leak being present has prompted me to
> > make running the CRM under Valgrind exceedingly easy. Simply give
> > the --enable-valgrind option to configure and all 5 CRM processes
> > will complain bitterly if they're leaking memory (with a stack trace
> > of who allocated it!). Just remember to start a Valgrind lister on
> > localhost:1234.
>
> Cool. You wouldn't be interested in making this available for all
> heartbeat processes, would you? ;-)
No really, for two reasons:
* generally they leave too much memory allocated when they exit (as
parts of the CRM did too) to make the results worthwhile
* the generic approach ends up profiling all the RAs and every
executable they call as well
If the owners of the remaining components wish to do this, then they
just need to add the prefix I set up in heartbeat/config.c
>
> I hope that we'll soon get feedback from Coverity as well again.
>
>
> > When running tools like Valgrind, please remember that there are
> > results that I cannot do anything about. Eg:
> > * library functions that leak every time they're called
>
> Are there any of these on SLES?
various heartbeat client libraries do this, so yes.
however I've not the time/energy to maintain the entire repository on
my own nor to force the various owners to take an interest.
> > * library functions that create "global" data and offer no way to
> > clean it up^
> >
> > For this reason, I have created a Valgrind suppression file which I
> > can make available if people are interested.
>
> Yes, can you please just check that into hg as well?
can do. it might even be a good idea to install it into /usr/lib/heartbeat
More information about the Linux-HA-Dev
mailing list