Memory leak in Glib

Platform
1

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.

2

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

3

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

4

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.

5

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.

6

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

7

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.

8

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.

9

Hi All,

Once again thanks for the comments.

As I mentioned earlier, we are trying to build debug version of GStreamer and Glib to get more information on call trace.

But still, we have tried one of the fix to address our application crash issue. As part of the fix, we have moved the g_main_loop_run to g_idle_add function. After the fix, we observed the memory leak.

Could any one please comment on the adding the g_main_loop_run in g_idle_add api ? Adding the gmain loop in the idle queue will cause any issue on clearing memory ?

Thanks,
Gokila

10

It sounds like you are probably confused and are doing something wrong.

Do you have only one main context? That would be the most common case.

  • If you only have one main context, then how is your idle callback ever called if the main context is not already being iterated? If the main context is already being iterated, you almost surely do not want to try iterating it recursively (this would be dangerous), so running the main loop from an idle callback doesn’t sound good. And if the main context is not already being iterated, then your idle callback is not ever going to be called, so that doesn’t sound good either.
  • If you have multiple main contexts, then we don’t have enough information to answer your questions, because you haven’t explained how your app uses main contexts.
11

And to add to that: without seeing your code, we cannot really help answer questions about it. Please post a link to the relevant bit of your code if you have further questions.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.