On Sun, 25 Nov 2007, Lennart Poettering wrote:
On Sun, 25.11.07 23:23, Jaroslav Kysela (perex@perex.cz) wrote:
I cannot reproduce here and from first glance, the error path in snd_config_hook_load_for_all_cards is good.
I don't fully grok the code of that function (snd_config_hook_load_for_all_cards()), but from *my* first glance I see that snd_determine_driver() allocates the string. Immediately after that call there are at least two "continue"s which will cause immediate jumping to the next iteration of the loop this whole code lives in, without ever freeing the string.
Or am I blind or missed something?
No, I'm blind (seeing and associating continue to inner while) ;-) Thanks for notice. This commit should fix the problem:
Hmm, I still don't fully grok the function, but doesn't this commit change the behaviour of the function quite a bit?
I am not sure due to what kinds of errors snd_config_get_string() or snd_config_search() might fail, but the names of those functions sound a bit like configuration errors might be one reason for the failure. Before this commit, on such an error the code would just go ahead with the next card. Now, on such an error the loop is terminated immediately. Sounds like a big change in behaviour to me.
I don't see a change in behaviour. The __err section just frees only fdriver variable (private_data is NULL and err is >= 0 - see line 2896). Because card >= 0 (2896 line), while on line 2923 will continue (thus next card will be processed too). I hope I've not overlooked something, too.
Any idea on that other valgrind bt I posted? Some leak with snd_config_make() involved?
Please, give use a simple testcase. This issue might be difficult to investigate without it.
Thanks, Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project