Weekly Edition
Return to the Development page
| |||||||||||||
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal)
Reg. Charney
demonstrates
a Valgrind profiling session in a Linux Journal article.
"Memory and performance problems plague most of us, but tools are available that can help. One of the best, most powerful and easiest to use is Valgrind. One thing stands out when you use Valgrind--you do not need to recompile, relink or modify your source code."
(Log in to post comments)
Access denied Posted Dec 2, 2004 20:48 UTC (Thu) by tarvin (subscriber, #4412) [Link] When I follow the link, I get a "Access denied - You are not authorized to access this page" page.
Access denied Posted Dec 3, 2004 3:49 UTC (Fri) by Duncan (guest, #6647) [Link] Worksforme. I'd suggest trying it again after some hours (which it hasbeen). Maybe they had difficulties? Duncan
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 8:17 UTC (Fri) by robbobkirk (guest, #26418) [Link] Valgrind is an absolutely superb tool that was almost entirely responsible for my company porting a large project from Tru64 (using cxx) and Windows to Linux (gcc) just to make use of Valgrind. In contrast Insure++ which is large $$$, is nowhere need as good as it requires full recompilation and generally crashes anyway.
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 15:25 UTC (Fri) by nix (subscriber, #2304) [Link] valgrind's implementation is one of those glorious mind-twisting hacks that *doesn't* have you kicking yourself asking `why didn't I think of it first?'
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 10:03 UTC (Fri) by zooko (subscriber, #2589) [Link] Valgrind rocks! It is an excellent tool for easily and precisely diagnosing all kinds of errors whilegiving very few false alarms.
But if you want profiling, you should use oprofile, which is also an excellent tool and which is
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 17:18 UTC (Fri) by iabervon (subscriber, #722) [Link] If you're profiling for memory usage (in the sense of determining whether your program is allocating, tracking, and deallocating a lot of memory needlessly), you might do better with valgrind. Valgrind, IIRC, can also tell you if your cache properties are good, including letting you specify the cache properties of a different machine, whereas oprofile will tell you what in your program is slow on your computer, but not necessarily that it's an issue of structure arrangement.
The feature I really want is a ddd/valgrind link, such that you can browse through the memory you've leaked. I've found it annoying to debug leaks in servers, where valgrind reports that I've leaked memory allocated by the protocol parser. The contents of that memory would tell me what path it took and therefore where to look for the missing free.
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 20:45 UTC (Fri) by evgeny (guest, #774) [Link] > Valgrind rocks!
Yes. If only I could use it on amd64...
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 15:30 UTC (Fri) by stuart_hc (guest, #9737) [Link] Valgrind is a tool I use on a daily or weekly basis and it has a number of advantages over Insure++ and Purify. Some projects have begun to include a valgrind-check make target. E.g. Dirac.But one type of bug it cannot detect which others can is stack array bounds checking. E.g. extern int main(void)
{
char str[8] = "hello";
str[8] = '\0'; // incorrect termination not detected by valgrind
return 0;
}
This limitation was not mentioned in the Linux Journal article but is mentioned in the valgrind FAQ item 5.2.
Valgrind 2.2.0: Memory Debugging and Profiling (Linux Journal) Posted Dec 3, 2004 15:50 UTC (Fri) by nix (subscriber, #2304) [Link] You really need compiler hacks to spot that sort of thing. There was a fat-pointer checking scheme in GCC enabled by -fbounds-checking, but was never completed and is moribund, and in practice would be very difficult to start using because it of necessity changes the ABI when you turn it on.
GCC 4.0 will be able to detect many of these classes of errors via the -fmudflap option, which is a narrow-pointer scheme working by instrumenting all indirections and variable declarations into calls to a runtime which checks for wild pointerness by consulting those lists of registrations (or at least that's how I understand it to work). It's got some overhead, but *much* less than valgrind.
|
|||||||||||||