[MPlayer-dev-eng] CONF_TYPE_STRING issue

[Ingo Brückl]

Reimar Döffinger wrote on Mon, 2 May 2011 19:16:04 +0200:

> On Thu, Apr 28, 2011 at 10:53:07AM +0200, Ingo Brückl wrote:
>> I was very surprised to find no such freeing, so either it's a
>> memory leak bug or I am doing something wrong.
>>
>> For example, I set name="foobar" in my user config and got:
>>
>>   # (copy_str, strdup) "foobar" at 0x91c9188
>>   # (before m_config_free) vo_winname = "foobar" at 0x91c9188
>>   # (m_option_free) name="foobar" at 0x91c9188
>>   # (free_str) "foobar" at 0x91c68d0
>>   # (m_option_free) name="foobar" at 0x91c9188
>> ### don't know why it's called twice, but 0x91c68d0 already freed, so no action
>>   # (after m_config_free) vo_winname = "foobar" at 0x91c9188
>>   # (manually freeing vo_winname now...)
>>   # (after freeing vo_winname) vo_winname = "^P^Har" at 0x91c9188
>>
>> So we see that the string "foobar" is created at 0x91c9188 and is still at
>> that address before m_config_free() starts. m_option_free() is called, but
>> then a "foobar" (slot?) at a different address (0x91c68d0) is freed. As a
>> result, "our" "foobar" is still present after m_config_free() and can be
>> freed by a simple free() (called "manually" in the output). After that, it
>> finally is gone.

> Not sure what exactly that was meant to show,

It shows that the allocated memory vo_winname is pointing to isn't freed by
m_config_free().

> However note that the values are stored twice: once in the
> program-accessible variable (vo_winname here I guess) and once in the
> "slot data". [...]

Again, thank you for your detailled answer which encourages me in my feeling
that after spending several hours with reading the code I've got a general
idea how that config stuff works.

> 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).

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m_config.patch
Type: text/x-diff
Size: 433 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110504/72da5511/attachment.bin>