I'd probably rename the env var used by the alloc tracer (which is something we no longer expose officially).

I know that people are actually using the alloc-trace stuff, and I also used it yesterday. We could make "live" and "live-mem" reserved names that can't be used by tracer plugins.

Or I just change mine to GST_TRACER. Maybe we can turn the alloctrace stuff into a tracer plugin in the long run and deprecate it. Then we can remove this in gst-2.0

The alloctrace stuff is not public API in 1.x, it's just there still for now. People use it interactively for debugging, I'm sure it's ok to just tell them to use another environment variable name to use if we wanted to?

Having said that, perhaps we should bikeshed the GST_TRACE name a bit more :)

GST_TRACER_PLUGINS looks more meaningful and readable to me, but I'm fine with GST_TRACE or GST_TRACER

commit 70d2a676af2bc51ed7b828dfd762b506bb82083b
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Mon Oct 19 21:39:19 2015 +0200

    tracer: rename the envvar to GST_TRACER_PLUGINS
    
    The subsystem reused the GST_TRACE var that is already in use by the alloc tracer.
    Fixes #756760

It would be nice to have some notes for how to use the alloc_trace stuff. If I get it, it counts the number of instances per type and can also build a list of the content. Finally the atexit handler dumps the leaked data. All this could be done with the tracing subsystem too, except that I did not use an atexit handler so far. I can take a stab at converting this into a tracer plugin, if that sounds like a good idea.

The main change would be that code like this:
#ifndef GST_DISABLE_TRACE
  _gst_alloc_trace_new (_gst_mini_object_trace, mini_object);
#endif
would be changed into a trace-point (that can also be used by other tracer plugins).

I'd prefer _MODULES to _PLUGINS myself, since the fact that they're a plugin is an implementation detail *ducks* :)

Me too, but whatever works!

Feel free to change it. I just wanted to fix the conflict for now.