|
From: Oliver S. <ol...@f-...> - 2012-05-04 17:51:17
Attachments:
signature.asc
|
Hi folks, 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? Basically the issue is that the program I am working on does a whole lot of initialization work. That initialization work is memory-intensive and that means it is relatively slow in Valgrind. However, for all practical purposes the process will always end up in exactly the same state at one point and I am thinking of whether there is a way to load that initial state, continue from there and then direct it to change its behavior in a particular way. To be a bit more specific. I'm running one of our command line AV scanners through Valgrind. The loading of the virus signatures at the beginning is the part that takes longest. It would be very practical to modify Valgrind in a way that allows it to resume from a "saved state". Thanks, // Oliver PS: I'm pretty sure I can convince my boss to invest time for this, if someone could provide the pointers where I would need to look. Currently I am working with the stock version of Valgrind that comes with Ubuntu 10.04 (x64). |
|
From: Philippe W. <phi...@sk...> - 2012-05-05 14:26:28
|
On Fri, 2012-05-04 at 17:32 +0000, Oliver Schneider wrote:
> Hi folks,
>
> 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.
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
...
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).
Philippe
|
|
From: John R. <jr...@bi...> - 2012-05-05 15:29:46
|
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. -- |
|
From: Oliver S. <ol...@f-...> - 2012-05-07 13:15:39
Attachments:
signature.asc
|
Hello Phillipe, thank you for your response. I think you gave me an idea. // Oliver On 2012-05-05 14:22, Philippe Waroquiers wrote: > On Fri, 2012-05-04 at 17:32 +0000, Oliver Schneider wrote: >> Hi folks, >> >> 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. > 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 > ... > > 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). > > Philippe |