[pulseaudio-tickets] [Bug 46989] New: Add support for the dmalloc memory checking tool.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46989

             Bug #: 46989
           Summary: Add support for the dmalloc memory checking tool.
    Classification: Unclassified
           Product: PulseAudio
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: medium
         Component: core
        AssignedTo: pulseaudio-bugs at lists.freedesktop.org
        ReportedBy: tanuk at iki.fi
         QAContact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net


The dmalloc (http://dmalloc.com/) tool is somewhat useful tool for checking
memory issues. Valgrind is probably "better", but it slows things down too much
in some environments.

The level of "support" I'd like to have in Pulseaudio is just including
dmalloc.h in pulse/xmalloc.c if HAVE_DMALLOC is defined. This is pretty useless
for tracking down memory leaks, because dmalloc only reports the immediate
caller of malloc(), which in case of Pulseaudio will always be pa_xmalloc().
There are checks for other errors than memory leaks, so dmalloc can still be
useful.

So, what needs to be done is adding this to pulse/xmalloc.c:

#ifdef HAVE_DMALLOC
#include <dmalloc.h>
#endif

In addition to that, Makefile.am of course needs some adjustment, and I'd like
to have --enable-dmalloc switch in the configure script.

Note that linking libdmallocth into libpulse requires dmalloc to be built with
-fPIC. That isn't enabled by default in dmalloc's build system, so this needs
to be mentioned in "configure --help" for the --enable-dmalloc switch. It would
be nice to check in the configure script whether the installed libdmallocth.a
is built with -fPIC, but I don't know how that can be done, or whether it's
even possible.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.