|
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: Dennis L. <pla...@in...> - 2006-03-12 16:22:18
|
Am Sonntag, den 12.03.2006, 15:32 +0000 schrieb Bryan Meredith: > 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. Not that its bad to do that, but I think its better to say "Omega shows also where the last pointer/reference to the allocated memory was lost". Saying "I know were the memory was leaked" would imply to infer the ownership of the object for the cases multiple pointers refer to it. Who knows, maybe the pointer that would have been the one responsible to free the memory has been lost way before another one that has been copied around is lost. So, maybe Omega could be extended to give (optional of course) reports on where pointers to that memory were lost, in order to better figure out where you should have freed it. greets Dennis |
|
From: Bryan M. <om...@br...> - 2006-03-12 16:36:36
|
Dennis, thanks for the suggestion - I personally think it is an excellent idea. The only way to make something like that work without drowning in the output of 10,000 free()d pointers would be to introduce a new client request to mark the memory block after it is created. As each tracked pointer is then added or removed, a trace report could be generated. If I get enough interest in this tool, I will look to implementing this as a feature before the 1.0 release. thanks, Bryan "Brain Murders" Meredith Dennis Lubert wrote: > Am Sonntag, den 12.03.2006, 15:32 +0000 schrieb Bryan Meredith: > >> 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. > > Not that its bad to do that, but I think its better to say "Omega shows > also where the last pointer/reference to the allocated memory was lost". > Saying "I know were the memory was leaked" would imply to infer the > ownership of the object for the cases multiple pointers refer to it. Who > knows, maybe the pointer that would have been the one responsible to > free the memory has been lost way before another one that has been > copied around is lost. > So, maybe Omega could be extended to give (optional of course) reports > on where pointers to that memory were lost, in order to better figure > out where you should have freed it. > > greets > > Dennis > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Christian P. <tr...@ge...> - 2006-03-20 06:30:05
|
On Sunday 12 March 2006 16:32, Bryan Meredith wrote: > see http://www.brainmurders.eclipse.co.uk/omega.html for a complete > overview of what this tool can do for you. neat ;) is there a chance to get this patch into upstream VG anytime soon? Regards, Christian Parpart. |
|
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: Bryan M. <om...@br...> - 2006-03-22 10:07:57
|
Jacek, the main reasons for putting out this beta release are to find out how well / how badly it works for other people and to get some feedback on what features are lacking. If you want to give me some idea of what you would need (preferably on the list so that others can join in if they interested) I would be happy to try and implement it. Bryan "Brain Murders" Meredith 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. > 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. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
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, |