while doing some research for krunner i came across a memory leak in KUriFilter which happens to get used quite a bit by konqueror and kdesktop (the latter for the current run dialog). it was a pretty innocent mistake in the code; in fact, i can see how it probably happened even: the initialization code was later re-used in a setter (also inlined, for good measure) but never ported for such use.
unfortunately, the bug isn't fixable in stable releases because the class's constructors are inlined as well as many setters, and the constructors in particular require modification so that fixing the memory leak doesn't cause crashes.
i'm always reminded of gems like this when people shrug off the seriousness of inlined methods in public interfaces. "but," they often say, "this'll never change. how could it? it's a single line of code and totally obvious!" indeed. getters you may be able to get away with; maybe. but setters and constructors? tempting fate just isn't worth it.
there are a lot of classes in kdelibs right now that still have inlined methods. from kurl in kdecore to classes in kio. there are also a number of classes in kio that still have strings of bools in their api, e.g. what does this do: KIO::listDir(path, false, false) ? yeah.
we've still got time to fix these things for kde4, namely the time between now and the 4.0 api freeze which is some months away. if you're looking for some entry level work that will get you aquainted with kdelibs, this a great opportunity.