tracers: leaks: sometimes reports leaks when CPU is heavily loaded
Describe your issue
When my CPU is heavily loaded, I sometimes got false positive leaks reports like this:
0:00:01.258992015 35628 0x563bb2226900 TRACE GST_TRACER :0:: object-alive, type-name=(string)(null), address=(gpointer)0x563bb22db820, description=(string)<sink>, ref-count=(uint)1, trace=(string);
0:00:01.259030064 35628 0x563bb2226900 TRACE GST_TRACER :0:: object-refings, ts=(guint64)11948270, type-name=(string)(null), address=(gpointer)0x563bb22db820, description=(string)reffed, ref-count=(uint)4, trace=(string);
0:00:01.259038416 35628 0x563bb2226900 TRACE GST_TRACER :0:: object-refings, ts=(guint64)1257284688, type-name=(string)(null), address=(gpointer)0x563bb22db820, description=(string)unreffed, ref-count=(uint)1, trace=(string);
(gst-launch-1.0:35628): GStreamer-WARNING **: 02:17:36.985: gst_mini_object_weak_unref: couldn't find weak ref 0x7f7f5a7d1450 (object:0x563bb22db820 data:0x563bb223ca00)
As you can see, type-name=(string)(null)
, meaning that g_type_name
returned NULL
(i.e. the object type was not loaded).
Expected Behavior
The leak is not reported, as it is probably a false positive
Observed Behavior
Leak of a type-name=(string)(null)
object is reported
Setup
- Operating System: Ubuntu 20.04 in a Docker environment
- Device: Virtual Machine
- GStreamer Version: 1.21.0.1 (main branch)
How reproducible is the bug?
Only when the CPU is heavily loaded, i.e. load > 48 on a 24 threads machine
Solutions you have tried
Working fixes:
- This MR just discard the null object so that it's not reported: !2752 (closed)
- This MR fixes the bug that
GstPadTemplate
type was wrongly considered as a mini_object: !2832 (merged) - This MR calls
g_type_class_ref (gst_pad_template_get_type ());
in gst.c (see Additional Information): !2829 (closed)
Related non-duplicate issues
Maybe related to #1334 (closed)
I think both issues are linked, because in my case, the GstPadTemplate
type was wrongly considered as a mini_object (hence the message gst_mini_object_weak_unref: couldn't find weak ref
afterwards).
With this MR !2832 (merged), the GST_OBJECT_FLAG_MAY_BE_LEAKED
is correctly checked, so that the leak is not reported
Additional Information
By checking on how the description=(string)<sink>
is generated, I guess from line 957 of gstinfo.c that this description means that the pointer if of type OBJECT
and that its name is sink
(I suppose the correct type in my case would be GstPadTemplate
), but it is really weird that the type is resolved at that time (in create_leaks_list
when calling leak_new
) but not afterwards (in process_leak
, when calling g_type_name
in gst_tracer_record_log
).
Would it be possible that the plugin could be unloaded between those calls?
Are there any thread-unsafe calls in gst_deinit()
, or are we sure that all plugins are unloaded when calling it?
It could explain the leak (i.e. the plugins may not be completely unloaded, but the tracer already process the leaks).
I also just found these:
With comment:
g_type_class_ref() our [..] type to make sure we avoid the thread-unsafe bits of the GObject/GType system, ie. bug #349410 and bug #64764. Should fix intermittent tee unit test failures (#474823).
Maybe a g_type_class_ref (gst_pad_template_get_type ());
is simply also needed? This merge request propose that: !2829 (closed)