Do you want to provide a patch for this?

Yes, I am preparing a patch to fix the bug and will upload it soon.

(In reply to Sebastian Dröge (slomo) from comment #1)
> Do you want to provide a patch for this?
Yes, I am preparing a patch to fix the bug and will upload it soon.

Please don't file bugs with "critical" severity unless they really are severe. Corner-case issues found by a static code analyzer are more often than not not critical.

In this case, there is no bug, the g_free is guarded:

        if (tmp[0] != '\0')
          g_free (tmp);

Ashish, anything left to be done here?

Yes, I can provide a patch, but will it be accepted considering Mr. Tim's opinion.(In reply to Sebastian Dröge (slomo) from comment #5)
> Ashish, anything left to be done here?

Yes, I can provide a patch, but will it be accepted considering Mr. Tim's opinion ?

Well, is your patch going to be correct? It seems like there's nothing to be changed here

I'm happy to accept a patch that improves the code to make it nicer. I'm just saying that the static analyzer is wrong and that there is no actual bug here in this particular case.

(In reply to Sebastian Dröge (slomo) from comment #7)
> Well, is your patch going to be correct? It seems like there's nothing to be
> changed here

It can be corrected if we remove below code segment which is redundant :-

LnNo.198        if (param_name)
LnNo.199          tmp = param_name;
LnNo.200        else
LnNo.201          tmp = (char *) ""; 


as 

LnNo.101  gchar *param_name = NULL;

and is not assigned anything till 
LnNo.204      param_name = g_strdup_printf ("%s\\n%s=%s", tmp, property->name,
              value_str);

Also we can modify the statements at LnNo. 204 and 207 as like below:
          param_name = g_strdup_printf ("\\n%s=%s",property->name,
              value_str);

Can you provide a patch? That makes it more clear what you mean

(In reply to Sebastian Dröge (slomo) from comment #10)
> Can you provide a patch? That makes it more clear what you mean

Ok, I will submit the patch.

Created attachment 356344 [details] [review]
Patch for the issue attached

Please review the patch and provide your feedback

Review of attachment 356344 [details] [review]:

::: gst/gstdebugutils.c
@@ +198,2 @@
         if (details & GST_DEBUG_GRAPH_SHOW_FULL_PARAMS) {
+          param_name = g_strdup_printf ("\\n%s=%s", property->name,

This is changing behaviour. You're not prefixing with the property_name anymore. Also below

Created attachment 356350 [details] [review]
modified patch

modified patch with prefixing by empty string.

(In reply to Sebastian Dröge (slomo) from comment #13)
> Review of attachment 356344 [details] [review] [review]:
> 
> ::: gst/gstdebugutils.c
> @@ +198,2 @@
>          if (details & GST_DEBUG_GRAPH_SHOW_FULL_PARAMS) {
> +          param_name = g_strdup_printf ("\\n%s=%s", property->name,
> 
> This is changing behaviour. You're not prefixing with the property_name
> anymore. Also below

----------------------------------
In the original code 'property->name' is always prefixed by an empty string as 'tmp' is always assigned empty string ""
------------------
LnNo.198        if (param_name)     //'param_name' always 'NULL' here
LnNo.199          tmp = param_name; //control never reaches here
LnNo.200        else
LnNo.201          tmp = (char *) "";
LnNo.202
LnNo.203        if (details & GST_DEBUG_GRAPH_SHOW_FULL_PARAMS) {
LnNo.204          param_name = g_strdup_printf ("%s\\n%s=%s", tmp, property->name,
LnNo.205              value_str);
LnNo.206        } else {
LnNo.207          param_name = g_strdup_printf ("%s\\n%s=%."
LnNo.208              G_STRINGIFY (PARAM_MAX_LENGTH) "s%s", tmp, property->name,
LnNo.209              value_str, ellipses);
LnNo.210        }

Removing prefixing of 'property->name' by an empty string should not make any difference.
But, if it is still changing the behaviour, please review the new patch attached in which 'property->name' is prefixed with an empty string.

(In reply to Ashish Kumar from comment #15)
> (In reply to Sebastian Dröge (slomo) from comment #13)
> > Review of attachment 356344 [details] [review] [review] [review]:
> > 
> > ::: gst/gstdebugutils.c
> > @@ +198,2 @@
> >          if (details & GST_DEBUG_GRAPH_SHOW_FULL_PARAMS) {
> > +          param_name = g_strdup_printf ("\\n%s=%s", property->name,
> > 
> > This is changing behaviour. You're not prefixing with the property_name
> > anymore. Also below
> 
> ----------------------------------
> In the original code 'property->name' is always prefixed by an empty string
> as 'tmp' is always assigned empty string ""
> ------------------
> LnNo.198        if (param_name)     //'param_name' always 'NULL' here
> LnNo.199          tmp = param_name; //control never reaches here
> LnNo.200        else
> LnNo.201          tmp = (char *) "";
> LnNo.202
> LnNo.203        if (details & GST_DEBUG_GRAPH_SHOW_FULL_PARAMS) {
> LnNo.204          param_name = g_strdup_printf ("%s\\n%s=%s", tmp,
> property->name,
> LnNo.205              value_str);
> LnNo.206        } else {
> LnNo.207          param_name = g_strdup_printf ("%s\\n%s=%."
> LnNo.208              G_STRINGIFY (PARAM_MAX_LENGTH) "s%s", tmp,
> property->name,
> LnNo.209              value_str, ellipses);
> LnNo.210        }
> 
> Removing prefixing of 'property->name' by an empty string should not make
> any difference.
> But, if it is still changing the behaviour, please review the new patch
> attached in which 'property->name' is prefixed with an empty string.

@Mr. Sebastian
Have you reviewed?

There's not really any bug here and this is a false positive in some static analyzer. The patch is correct but it makes the code harder to follow and does otherwise have no effect in the best case.