>I can see where that might be useful. We approximate >that by suppressing the leaks we don't care about; >having a single client request to say "suppress >all leaks seen up to this point" could be handy >if you don't have the time to keep a suppression >list up to date, e.g. when working on a large app >which doesn't normally use valgrind as part of its daily test.
An other usage pattern for this (which is the one for which we want this wish :) is to start a big application, and then run various tests on this started application (without restarting it each time, as this takes a lot of time in particular with valgrind). Then between each test, we report the leaks (and/or the additional memory allocated). This allows to make a direct link between a functional test (or part of a test) and a leak (or memory allocated). Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
