|
From: Dennis L. <pla...@in...> - 2005-08-12 10:42:12
|
Am Freitag, den 12.08.2005, 11:14 +0100 schrieb Tom Hughes: > In message <200...@ge...> > Christian Parpart <tr...@ge...> wrote: > I guess we could remember that history for a while like we do with > free blocks but it seems like it would have very marginal benefit. I think this is a general "problem". Valgrind is a great tool and many people use it, and now that there is the 3.0 release with amd64 support even more people do. What they do is, running valgrind on it, fixing the usual errors, and whats left is the not-so-usual errors. And as more and more people using valgrind, the chance that more and more people hit such errors rises. But I think helping those people to find there errors with valgrind (and thus future of those errors, or similars too) is what makes a tool really professional and probably best of all available... I currently work on an application where most of the code is loaded as plugins, and as a workaround I set a environment variable that tells the plugin mechanism to not dlclose() so that I have the symbols in the stack traces with valgrind. As I think lots of people use polymorphism for plugins have problems with this, so lots of people would benefit from a mechanism that keeps the symbols. The same is for different memory accesses... it would help if it could tell where it has been unmapped, or if it tells that its not stacked/malloced/freed but in this or that segment or similar. A tool like that should give as much information as possible, no matter if it seems helpful at first or not (thats why we have --verbose flags ;) I heard of some people who had problems like this when used valgrind and instead of complaining about it, they searched for other ways to debug their programs. So I think just because noone complains, a feature is not really unnecessary... some thoughts... greets Dennis |