|
From: Bryan M. <om...@br...> - 2006-03-12 15:33:20
|
see http://www.brainmurders.eclipse.co.uk/omega.html for a complete overview of what this tool can do for you. From the web page: ----------------------------------- Omega addresses what I perceive to be one of the few shortfalls of the excellent Valgrind Memcheck Tool - where Memcheck reports the location that a leaked block was allocated, Omega also shows where it was leaked. . . . OK. Let's run Memcheck and Omega on a small test program so you can see what to expect. 01 #include <stdlib.h> 02 03 static void func1(void) 04 { 05 char *pointer = 0; 06 07 pointer = malloc(64); 08 09 return; 10 } /* Leak report here */ 11 12 int main(int argc, char *argv[]) 13 { 14 func1(); 15 16 return 0; 17 } 18 Save that (without the line numbers) as scope2.c then compile it like this: $> gcc -g -O0 scope2.c -o scope . . . $> valgrind --tool=memcheck --leak-check=full ./scope ==13293== Memcheck, a memory error detector. ==13293== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==13293== Using LibVEX rev 1419, a library for dynamic binary translation. ==13293== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==13293== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation framework. ==13293== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==13293== For more details, rerun with: -v ==13293== ==13293== ==13293== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) ==13293== malloc/free: in use at exit: 64 bytes in 1 blocks. ==13293== malloc/free: 1 allocs, 0 frees, 64 bytes allocated. ==13293== For counts of detected errors, rerun with: -v ==13293== searching for pointers to 1 not-freed blocks. ==13293== checked 56,168 bytes. ==13293== ==13293== 64 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==13293== at 0x401B51E: malloc (vg_replace_malloc.c:149) ==13293== by 0x8048372: func1 (scope2.c:7) ==13293== by 0x804838F: main (scope2.c:14) ==13293== ==13293== LEAK SUMMARY: ==13293== definitely lost: 64 bytes in 1 blocks. ==13293== possibly lost: 0 bytes in 0 blocks. ==13293== still reachable: 0 bytes in 0 blocks. ==13293== suppressed: 0 bytes in 0 blocks. ==13293== Reachable blocks (those to which a pointer was found) are not shown. ==13293== To see them, rerun with: --show-reachable=yes As expected, Memcheck identifies that the block allocated at line 7 has leaked. Whilst with this trivial example, its obvious where the leak occurred, tracking down memory leaks can be a really tedious and time consuming exercise. So, lets try Omega to see if it can help us out: $> valgrind --tool=omega ./scope ==13297== Omega-beta2, An instant memory leak detector. ==13297== Copyright (C) 2006, and GNU GPL'd, by Bryan Meredith. ==13297== Using LibVEX rev 1419, a library for dynamic binary translation. ==13297== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==13297== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation framework. ==13297== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==13297== For more details, rerun with: -v ==13297== ==13297== ==13297== ==13297== ==13297== Omega Leak Summary ==13297== ================== ==13297== Loss Record 1: Leaked 64 (0x40) bytes in 1 block ==13297== at 0x8048379: func1 (scope2.c:10) ==13297== by 0x804838F: main (scope2.c:14) ==13297== Block allocated ==13297== at 0x401AE7E: malloc (vg_replace_malloc.c:149) ==13297== by 0x8048372: func1 (scope2.c:7) ==13297== by 0x804838F: main (scope2.c:14) ==13297== See the difference? Omega not only shows that the block allocated at line 7 leaked, it shows you that it leaked at line 10. . . . Omega is NOT perfect. I hope that it will get better but it is fairly usable NOW. It currently supports x86 and x86_64. The main area that I expect to work on to get this up to release standards is function wrapping. With the highly optimised routines in glibc and other libraries, Omega can sometimes lose track of a pointer as it gets moved or miss making a new one on a copy. By introducing function wrappers around these problem functions, we should be able to ensure that the right thing happens. I would welcome assistance to make this work on PPC32 and PPC64 but I have no hardware to test or build on so I would need patches rather than just helpful advice. I am more than happy to receive your comments, criticisms, bug reports and especially patches (although I make no promises to accept them). Any success stories would also be nice to hear about. ----------------------------------- All the information that you need to download, compile and run Omega is on the web page. If you are having problems tracking down memory leaks, Omega is designed to help YOU. Bryan "Brain Murders" Meredith |
|
From: Jacek P. <ja...@s3...> - 2006-03-22 09:22:54
|
Hello Bryan. > see http://www.brainmurders.eclipse.co.uk/omega.html for a complete > overview of what this tool can do for you. We are using Valgrind for our automatic nightly testsuite. Omega looks very interesting, but lacks one important feature - XML output. We need it, because Valgrind output is processed by our scripts (to show every error and leak on nice looking website), and XML is much better to process than plain text. Are there plans in close future to support XML output in Omega? The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: com...@s3.... Thank You. |
|
From: Ashley P. <as...@qu...> - 2006-03-22 10:08:24
|
On Wed, 2006-03-22 at 10:22 +0100, Jacek Poplawski wrote: > Hello Bryan. > > see http://www.brainmurders.eclipse.co.uk/omega.html for a complete > > overview of what this tool can do for you. > We are using Valgrind for our automatic nightly testsuite. > Omega looks very interesting, but lacks one important feature - XML output. > We need it, because Valgrind output is processed by our scripts (to show > every error and leak on nice looking website), and XML is much better to > process than plain text. I'd be very interested in seeing the code for this, I've been hacking at the XML code for a while and hope to be submitting some fixes in this area soon. Ashley, |