Memory leak in Glib

Hi,

We have integrated GStreamer 1.22 with our application and started seeing memory leaks. We have captured the UMDH snap shots to identify the memory leak. It is pointing to one of the libglig api. Kindly let us know if any change made recently on this api (version 2.72).

image

Thanks in advance.

Are you freeing the argvp return value from the g_shell_parse_argv() call?

Hi,

We are not calling the function `g_shell_parse_argv()’ directly in our application. We are calling few of the glib functions,

g_main_loop
g_source_remove
g_idle_add
g_object_set
g_signal_connect
g_value_dup_strin
g_value_unset

Do you have any idea, any one of these function internally invoke g_shell_parse_argv ??

Thanks

None of those functions call g_shell_parse_argv(). I suggest you look at the full stack from your leak report and then read through the code of the functions being called (it’s all open source) to work out which bit of code ends up owning the memory allocated by g_shell_parse_argv() and not freeing it.

And if you can’t figure it out yourself, then post the full stack (preferably in text format rather than a screenshot) as without seeing the stack it won’t be possible for anybody to provide much help.

Note that g_shell_parse_argv+11A1 could even be a different function than g_shell_parse_argv! Most likely the debugger is using positions relative to named exports. I suggest building a debug version of GLib

Hi,

Thank you all for your comments.

We have integrated our application with the GStreamer which internally uses GLib. We are trying to build the debug version of GStreamer now.

Meanwhile, we would like to understand few scenarios on GLib. We have made code so that GMainloop will be created and quit on the EOS. We do unref of the GMain loop means clearing the loop and objects properly. But still, we do see a memory leak in GLib. We have used UMDH logs to identify the leak in our application. The first 2 highest allocations are pointing to Glib api’s as follows,

+   40000 ( 2190000 - 2150000)    219 allocs	BackTrace58E864C
+       4 (   219 -   215)	BackTrace58E864C	allocations

	ntdll!RtlpCallInterceptRoutine+26
	ntdll!RtlpAllocateHeapInternal+29C
	ntdll!RtlAllocateHeap+32
	ucrtbase!_malloc_base+25
	**libglib-2.0-0!g_shell_parse_argv**+11A1

+    f330 ( ae0eb4 - ad1b84)  a66e2 allocs	BackTrace58E86D4
+     f33 ( a66e2 - a57af)	BackTrace58E86D4	allocations

	ntdll!RtlpCallInterceptRoutine+26
	ntdll!RtlpAllocateHeapInternal+29C
	ntdll!RtlAllocateHeap+32
	ucrtbase!_malloc_base+25
	**libglib-2.0-0!g_malloc**+1B

We have tried to add g_main_loop_run via g_idle_add but still we see issues. Any other suggestion helps us.

Thanks in advance.

As Luca says, looking at leak backtraces is pointless until you’ve built and are running with a debug version of GStreamer and GLib. Those backtraces are not giving you any useful information as the symbol information isn’t all there.