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).
Thanks in advance.
Are you freeing the
argvp return value from the
We are not calling the function `g_shell_parse_argv()’ directly in our application. We are calling few of the glib functions,
Do you have any idea, any one of these function internally invoke g_shell_parse_argv ??
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.
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
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
+ f330 ( ae0eb4 - ad1b84) a66e2 allocs BackTrace58E86D4
+ f33 ( a66e2 - a57af) BackTrace58E86D4 allocations
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.