[CRIU] Restore failed. Exit code: 43

[Pavel Emelyanov]

On 01/26/2015 08:05 PM, Paschalis Mpeis wrote:
> My initial thought was to fork the initial process, so as to exploit the copy-on-write fork implementation on Linux.
> 
> Then the forked process will call the function, and the parent will make the dump, by providing the PID of its child.

This would work, but will anyway dump the whole process. In order to dump only what it relevant
to a single function... hmm... you should either explore the binary with disassembler or...
maybe the memory tracked would help. You reset the tracker, then start working. Then you
call criu to dump the process and dump only what memory has changed. This will include only
what was touched by the function.

And on restore time you should create the process and ask CRIU to repopulate only part of
it. But this functionality is not yet there, criu should be patched to allow for this.

> How does this sound to you? I don't know if its feasible, I 'll just try to give it a shot!
> 
> I 'll also have a chat about it with my research advisors, and get back to you!
> 
> 
> Cheers,
> Paschalis
> 
> On Mon Jan 26 2015 at 2:46:01 PM Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
> 
> 
>     >     I would be happy to help, but I don't understand what "function-only" capturing means. Can
>     >     ​ ​
>     >     you describe your scenario in more details?
>     >
>     >
>     > Currently, I dump a program before the execution of the function daxpy. Then, I can replay
>     > the program from that point onwards. That replaying is basically like a resuming from that point, and
>     > I can ​do it
>     >  as many times as I want, since I have kept in disk some image files.
>     >
> 
>     Great! :)
> 
>     > So, dump has captured all information needed not only by the "daxpy" functions, but also for the rest of the program.
>     >
>     >
>     > What I want, is to execute let's say in isolation the function "daxpy". Then on dump,
>     >  I want t
>     > ​he contents of the images to be just the
>     > necessary information that the function
>     > ​"​
>     > daxpy
>     > ​"​
>     > needs.
>     > ​Such information are
>     > :
>     > ​.the parameters of "daxpy"
>     > .the code of the functions that are being called by the "daxpy"​
>     > .the global variables that are "touched" by "daxpy", or by the functions that are called by "daxpy"
>     >
>     > With this information, I will NOT be able to resume the program. But, I will be able to replay just the function "daxpy".
> 
>     Oh, I see. That would be an interesting feature indeed. But I'm not an expert in compilers
>     to say whether it's possible at all to find out the part of the in-memory state of a process
>     that only "relates" to some function :)
> 
>     > Once again, thank you very much Pavel for your prompt and really informative replies!
> 
>     You're always welcome!
> 
>     Thanks,
>     Pavel
> 
> 
> 
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>