My found and lost faith in tools of runtime debugging

Okay, I was never much a lover of runtime debugging; I already said that before. Although there are people like Darren Reed from Sun, who wouldn’t work without a runtime debugger, I’m more for a classical, maybe rude, way of debugging: adding printf() where I want to inspect code and looking at compiler’s warnings to look for problems and finally checking the code path statically to find missing stuff.

Yesterday chutzpah suggested me to looking at valgrind to find possible leaks within xine. I didn’t know much on using it, but I started looking at the documentation trying to grasp the way it works, and finally started looking at it.

But this didn’t fly that well at all. First of all, seems like xine-ui doesn’t like cleanup its way before quitting so it’s quite difficult for me to find the leaks in xine-lib code on a quick glance. Okay chutzpah already pointed out that the kernel cleanups anyway the memory occupied by the process, but trying to not add leaks at all is, IMHO, important on design, and useful for this kind of dynamic checking, too.

Then there’s another problem, that’s even more annoying, as xine-ui can be fixed somehow, but this requires way more experience than I have. The problem is that my system is entirely built with -ggdb (so with debug information), but using splitdebug all the information required for debugging, including the symbols table (symtab) it’s stored in the .debug file inside /usr/lib/debug. What does that mean? That to know which function and which library is actually an instruction at you need to take all the data out of that file. Unfortunately seems like valgrind is able to get the debug information out of the debuglink but not the symbols’ table, thus I get pointless backtraces in the output, sigh.

I think I won’t find much use of valgrind myself right now, at least until the debuginfo stuff and I can actually look at xine-ui’s code so that I find why it doesn’t cleanup correctly.

Talking about xine, I’m afraid the biggest waste of memory is due to the way plugins are loaded, at least if I didn’t get the code wrong. Basically plugins are loaded in memory during the first check, then they are left in memory, and the ones needed to play the files are loaded aftwards (being already loaded they shouldn’t be loaded twice, I suppose). This unfortunately leads to strange behaviours, like amaroK loading the whole set of postplugins also if they aren’t needed at all.

Albeit, either there is some cleanup or there’s a way to tell xine not to load video plugins, as I can’t find video_out plugins being loaded (but there are already enough pointless plugins loaded like spu* and real — that i still think it’s not working anyway on AMD64). I’ll have to look more at the API, that’s something I never considered before, also because it might be interesting to just use -fvisibility=hidden for the whole stuff and exporting only the public API. Unfortunately such a change would require a complete testing with all – or at least the major – frontends.