On 2/10/07, Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
On 2007-02-09T16:43:50, Andrew Beekhof <[EMAIL PROTECTED]> 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
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
