GNOME Bugzilla – Bug 700586
GstTaskPool possible leak
Last modified: 2013-05-20 15:44:55 UTC
I'm creating a bin to decode a Transport Stream. The bin/elements are: o created o inserted into the pipeline using an input-selector o played o disconnected o set to NULL state o destroyed This works fine. However, there are a number of memory leaks that I'm tracking down. Each time we lose around 4KB in around 150 chunks. One of the leaks is a string "<queue name>:src". This turns out to be the name of a thread. I think the problem is related to gst_task_join. It does: if (pool) { if (id) gst_task_pool_join (pool, id); gst_object_unref (pool); } The id is zero and the pool_join is skipped. The reason that the id is zero is that gst_task_pool_push (default_push) returns zero normally. The documentation says this is OK. Removing the if (id) seems to fix the problem. However, I'm not familiar enough with the code to be sure that this is the right thing to do.
Why would that fix anything? default_join() does not do anything, so gst_task_pool_join() for NULL and the default pool would do nothing. Can you get a valgrind log of the leaks, including --track-origins=yes? This sounds like somewhere GstTasks are leaked.
I see your point about gst_task_pool_join(). I'll back out my change and see if that makes any difference. I'll add another comment when I have results. I'm woring under Windows/MinGw. I don't think valgring is an option.
I backed out my change and the leak is still gone. I now realize, that another change that I made, to my application, must have fixed that particular leak. Sorry for the trouble. Please close the bug report as "Not a bug". BTW. Is valgrind an option on Windows/MinGw?
No, but there is this project: http://sourceforge.net/p/valgrind4win/wiki/Home/ Don't know the status though