[CRIU] Restore failed. Exit code: 43
Paschalis Mpeis
paschalis.mpeis at ed.ac.uk
Mon Jan 26 09:05:27 PST 2015
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.
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>
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150126/efd00771/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150126/efd00771/attachment.ksh>
More information about the CRIU
mailing list