[MPlayer-dev-eng] CONF_TYPE_STRING issue

[Reimar Döffinger]

On Wed, May 04, 2011 at 02:51:28PM +0200, Ingo Brückl wrote:
> Reimar Döffinger wrote on Mon, 2 May 2011 19:16:04 +0200:
> > The slot data is there to allow "pushing" and "poping" configuration.
> 
> And the program-accessible variable is "set" from such slot data (strdup'ed
> in case of char *variable) which leads to the leak.
> 
> When the slot data and the slot itself (one or multiple slots) have been
> freed, the allocated data for the program-accessible variable (from the last
> "set slot to variable") is still present and won't get freed. See attached
> patch proposal (in which I've added a few more preceding lines for better
> clarification).

I don't think that's correct.
In MPlayer code you might have
char *option = "value";
to set some default, and your code would end up
calling free on that "value" pointer if the option
was never set, which is not correct.
Though I admit I am not sure if this works correctly
even currently.
If you can show and actual memleak (e.g. something that
valgrind puts in the category "definitely lost") it
should be easier to figure out where to put a free.