On 05/05/2012 07:22 AM, Philippe Waroquiers wrote: > On Fri, 2012-05-04 at 17:32 +0000, Oliver Schneider wrote:
>> I've got a question about Valgrind and its Memcheck tool. Is it possible >> to take a snapshot of a program under Valgrind, kinda similar to the way >> a fork() clones the process space, and then continue again from that >> snapshot with Valgrind? Could fork() perhaps be the answer? > This is not possible with Valgrind. The current code of valgrind cannot handle "save, restore, and continue", but perhaps the original poster is highly motivated and skilled at making modifications. Also, if the application itself might be extended to do the fork(), with the child willing and able to wait a long time to be given a new task via some mechanism, then the outward appearance of the resulting behavior might be close enough to what is desired. Adding a feature to the application, so that the application does "fork, then child awaits a task", might well be the easiest way to proceed. If the app can be modified, then this is definitely the place to start. If changing the app is totally off limits, then one is forced to modify valgrind. Intercept some signal, do the fork(), then child somehow finds the description of its new task and "force feeds" it into the app. > Having a fully general "snapshot" solution looks close to impossible > e.g. you have to re-create the exact "system state": > opened files and seek position > tcp/ip connections > pwd > ... > All that it true, but perhaps in this case not much of it matters. The set of open files might be empty, or might consist only of stdin, stdout, and stderr with no pending data. There might be no network connections, the working directory might be irrelevant, etc. See http://bitwagon.com/jumpstart/jumpstart.html for an example which "preloads" shared libraries, making a new app that effectively bypasses the loading of shared libraries, thus saving wall-clock time for subsequent "invocations." > The closest to what you describe here that I know of is the "unexec" > feature of emacs: emacs is first compiled, it has no lisp loaded. > As part of the build, it then loads a whole bunch of lisp files > and then "unexec" itself (i.e. creates a dumped executable) > After that, the dumped file is the one which is installed, with > loaded lisp files being part of the initialised data. > > So, I guess you better work in that direction (or have a data > structure that you can e.g. dump to a file to just mmap at startup). This is one technique that can work in some cases. However, if there are any "holes" for padding or alignment in the data structure, or the region contains an allocation arena, then dump-and-mmap "fills in" all the holes: turns any uninit bytes or unallocated areas into allocated- and-initialized. So dump-and-mmap can lose information that is vital to getting good results from memcheck. Writing code to handle such cases "correctly" probably takes too long to be worth it. -- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
