[Bug 766008] New: Improve leaks detection using GST_TRACE

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766008

            Bug ID: 766008
           Summary: Improve leaks detection using GST_TRACE
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gdesmott at gnome.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

As suggested on bug #765540 I tried a new approach to filter out objects which
are intentionally "leaked".
I did so by introducing a new flag on Gst(Mini)Object allowing us to explicitly
mark such objects in the code.
I then played with GST_TRACE in order to determine if it could be used as a
proper leaks detection tool.
I'm pretty happy with the results so far! I fixed quiet a bunch of leaks in
gst-validate and core. All the core tests are now passing with no leak
detected.

See this branch for the code:
https://git.collabora.com/cgit/user/cassidy/gstreamer/gstreamer.git/log/?h=trace-leaks

This kind of tool is not going to be a full replacements of valgrind but I
think it could be a nice addition to our toolbox.
I see the following advantages in this approach:
  - Much lighter to use than valgrind, which should make it usable on embedded
device with low ressources (I didn't try this yet).
  - Integrated in core so no need to build external tools which can sometime be
problematic on some platform/devices.
  - Much faster than valgrind so can easily be run with "make check" to
detect/prevent leak regressions.
  - Better control on what is being filtered out; valgrind suppression files
can be a pretty big hammer.
  - Track only leaks in gst code so should be more robust and consistent
accross different platforms or system lib versions. This is important to reduce
the "noise" if we integrate this as part of our automatic QA.

I'm still not sure if GST_TRACE is the proper tool for that, but we could
easily implement similar features using a GstTracer.

For the record here is the list of bugs I found during this experimentation:
https://phabricator.freedesktop.org/D958
https://phabricator.freedesktop.org/D959
https://bugzilla.gnome.org/show_bug.cgi?id=765706
https://phabricator.freedesktop.org/D979
https://phabricator.freedesktop.org/D980
https://bugzilla.gnome.org/show_bug.cgi?id=765719
https://bugzilla.gnome.org/show_bug.cgi?id=765720
https://bugzilla.gnome.org/show_bug.cgi?id=765903
https://bugzilla.gnome.org/show_bug.cgi?id=765904
https://bugzilla.gnome.org/show_bug.cgi?id=765957
https://bugzilla.gnome.org/show_bug.cgi?id=765958
https://bugzilla.gnome.org/show_bug.cgi?id=765961
https://bugzilla.gnome.org/show_bug.cgi?id=765976
https://bugzilla.gnome.org/show_bug.cgi?id=765978

So, is that something we could consider adding to core at some point?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.