From ee346fbad6f65930f2becc660e802b3bab125593 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim-Philipp=20M=C3=BCller?= Date: Thu, 28 Jun 2012 14:41:43 +0100 Subject: [PATCH] docs: expand a bit more on GST_DEBUG docs --- docs/gst/running.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/gst/running.xml b/docs/gst/running.xml index ce64a2481f..b6bf59a676 100644 --- a/docs/gst/running.xml +++ b/docs/gst/running.xml @@ -201,7 +201,12 @@ For example, setting GST_DEBUG to To get all possible debug output, set GST_DEBUG -to +to . For debugging purposes a debug +log is usually the most useful, as it contains all important information, but +hides a lot of noise such as refs/unrefs. For bug reporting purposes, a + log is also what will be requested usually. It's often +also worth running with to see if there are any +non-fatal errors or warnings that might be related to the problem at hand. @@ -298,7 +303,8 @@ The variable takes a comma-separated list of tracing options to enable. Keep track of the unfreed memory pointers and dump an overview of all unfreed memory at program exit. Together with a level 9 debug log this can be used to follow the lifecycle of leaked objects in order to track down where they are - leaked. + leaked. This can be useful for debugging memory leaks in situations where + tools such as valgrind are not available, or not an option.