BParameterGroup::Unflatten() leaks fName

[ttcoder]

This sequence.. ​http://xref.plausible.coop/source/xref/haiku/src/kits/media/ParameterWeb.cpp#623

creates a new BParameterGroup and immediately calls Unflatten() on it.. But Unflatten() is not a well behaved citizen

This means the original fName ("unnamed") is leaked, losing 8 bytes whenever the playback volume is queried or set

[ttcoder]

Details:

The ​call to ​read_string_from_buffer() assigns it a new malloc()ed block without freeing the original alloc from the ctor

And thus the one from the ctor is leaked, and appears in leak_analyzer.sh outputs like this:

allocation: base: 0x8a4eff8; size: 8; thread: 3788; alignment: 8
        <libroot.so> panic(char const *,...) + 0x41ae (nearest)
        <libroot.so> panic(char const *,...) + 0x4699 (nearest)
        <libroot.so> panic(char const *,...) + 0x5c13 (nearest)
        <libroot.so> panic(char const *,...) + 0x5c42 (nearest)
        <libroot.so> malloc + 0x25
        <libroot.so> strndup + 0x45
        <libmedia.so> BParameterGroup::BParameterGroup(BParameterWeb *, char const *) + 0x46
        <libmedia.so> BParameterWeb::Unflatten(unsigned long, void const *, long) + 0x248
        <libmedia.so> BMediaRoster::GetParameterWebFor(media_node const &, BParameterWeb **) + 0x236
        <libmedia.so> BSoundPlayer::_GetVolumeSlider(void) + 0x46
        <libmedia.so> BSoundPlayer::_Init(media_node const *, media_multi_audio_format const *, char const *, media_input const *, void (*)(void *, void *, unsigned long, media_raw_audio_format const &), void (*)(void *, BSoundPlayer::sound_player_notification,...), void *) + 0x7ff
        <libmedia.so> BSoundPlayer::BSoundPlayer(media_raw_audio_format const *, char const *, void (*)(void *, void *, unsigned long, media_raw_audio_format const &), void (*)(void *, BSoundPlayer::sound_player_notification,...), void *) + 0x98

read_string_from_buffer() should probably free(*_string) before assining the new value *_string = string;

I'm tracking bigger leaks, but getting my feet wet with this easy one first. Let's see if this gets a response...

[Barrett]

I don't have much more to add, I think your proposed solution is OK. I'm going to test it though before to commit the fix. Thanks for reporting those issues!

[Barrett]

Fixed in hrev50187.

[ttcoder]

Thanks much Barrett! Motivates me want to send more fixes :-)