<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It's much clearer now, thanks :) So what I see happens there.<br>
<br>
You start a process A to be the main.c's main with "1" as an argument. At some point A calls the<br>
dumpApplication(). The dumpApplication() fork()-s kid B and A waitpid()-s for it. B calls the<br>
criu_dump() which dumps the B process and leaves it running. B sees 0 ret code from criu_dump()<br>
and then exit()-s with ret-code SUCC_DUMP_ECODE. It's parent (the A task) waits the kid, checks<br>
for exit status being SUCC_DUMP_ECODE() and prints the<br>
<br>
== Captured successfully ==\n\n<br>
<br>
message, then dumpApplication() ends, A continues execution. This pretty much coincides with what<br>
is there in the output file.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Next you want to replay and start new process, C, with the main.c's main as entry point and the<br>
"2" as an argument. OK. In this case the restoreApplication() is called immediatelly. The latter<br>
calls criu_restore_child(). Now what happens here is complex, confusing, but very interesting and<br>
kinda unavoidable :) C forks() new child process D, when D is created it is "restored" by criu and<br>
is put into the former B's state -- the state as if it is in the dumpAplication() call returning<br>
from the call to criu_dump(), but getting the code 1 (not 0 as it was in B) into ret variable in<br>
there. Next D will behave just like B did with the only difference that ret is 1, not 0, which<br>
will be decoded into SUCC_RSTR_ECODE by this check<br>
<span><br>
if (ret ==0)<br>
ret = SUCC_DUMP_ECODE;<br>
else if (ret ==1)<br>
ret = SUCC_RSTR_ECODE;<br>
else<br>
ret =1;<br>
<br>
</span>and then D will call exit(ret) thus exiting with SUCC_RSTR_ECODE code. The D's parent (C) will<br>
be woken up from the waitpid() call (line 119 of crlib.c) and will just exit. So this is what you<br>
should get and do get.<br>
<br></blockquote><div><br></div><div><div><span style="font-family:verdana,sans-serif">Hmmm...<div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"> There are in total 4 processes: A & B for capture, and C & D for restore.</div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">So for each capture or restore, there are two exit points (when each process terminates).</div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline">Lets name the process that does CRIU magic for capture the "capturer", and the process that does CRIU magic for restore, the "restorer".</div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline"><br></div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline">From what you have told me, I have understood the following:</div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline"><br></div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline"><b>Capture:</b></div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline">Process A is my program. Then, it is forked, so we have B, in which you do your magic, so my program is captured. B is a "capturer". Right?</div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline"><br></div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline">So, when B continues, it does staff unrelated to my program, maybe some CRIU staff, and then it finally exits.</div></span></div><div><span style="font-family:verdana,sans-serif"><div class="gmail_default" style="display:inline">Then, process A, waits for the dump to be finished, and when this happens, it continues execution. Specifically, A will continue executing from line 30 <a href="https://gist.github.com/Paschalis/a96b2747ed85b8e5a796#file-linpack_h1_-c-L30" target="_blank">here</a>.</div></span></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">Is that correct?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Also, I have a question regarding command "<span style="font-family:arial,sans-serif">criu_set_leave_running(</span><span style="font-family:arial,sans-serif">true</span><span style="font-family:arial,sans-serif">)".</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:arial,sans-serif">It will be executed by child B, right? Why should I bother setting this, since B is the capturer?</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:arial,sans-serif">What I thought this setting was, is that it let process A continue its execution (not B), after the dump occurred.</span></div><br></div><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif"><b>Replay:</b></div><div class="gmail_default" style="font-family:verdana,sans-serif">C starts execution. It calls restoreApplication() <a href="https://gist.github.com/Paschalis/a96b2747ed85b8e5a796#file-main-c-L30" target="_blank">here</a>. Then, C is forked so we have process D.</div><div class="gmail_default" style="font-family:verdana,sans-serif">Is C the "restorer"? (I am bit confused about this)</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Then you say that D is restored into B state. I do not want this, since B is the "capturer" and not my program.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I suspect this is not what you planned to see. Most likely you want D to continue doing what A<br>
was, not B.</blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif">Yes, I want precisely this. Given that I have described the processes A, B, C, and D above correctly.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In that case you should fix the dumpApplication() code not to exit() upon seeing the<br>
SUCC_RSTR_ECODE, but to return from this function. This is the unavoidable nature of dump and<br>
restore. If you dumped yourself (this is what dumpApplication does) and then restored, you get<br>
back in time into the state where you have been right after you have requested to dump yourself.<br>
<br>
The mentioned check for ret that sets one of SUCC_*_ECODE values is differentiating these two<br>
cases -- whether you have just being dumped, or have just being restored.<br>
<br>
Is this explanation clear and helpful?<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">So basically, I will exploit that D will be magically travel-in-time into "dumpApplication" function, right after the dump, and I will not terminate it. I will try this right away. I hope that I won't run into further problems! :)</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Ultimately, I'd want to capture and replay just one function. Do you provide any API calls for doing such thing? One solution might be capture everything, as I do right now, and then instrument the function I want to exit right after execution. However, that would have stored in images lot of unnecessary program state!</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The explanation was extremely extremely helpful. Are these explanations somewhere in your wiki pages? A simple description of these 4 processes on a capture and restore would have been extremely helpful for all naive users!</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Now I have questions about your output and expected-output. The lines<br>
<br>
##########################################################<br>
##### HERE IT IS THE OUTPUT OF THE LINPACK EXECUTION #####<br>
##########################################################<br><br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">This was the output that the main_linpack.c produces. See <a href="https://gist.github.com/Paschalis/a96b2747ed85b8e5a796#file-main_linpack-c-L178" target="_blank">here</a>.</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">I just replaced this output with the above 3 lines so you could read it more easily!</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"></div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
After waitpid!<br><br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">This is a printf that I have removed from the gist code. It was put in this line <a href="https://gist.github.com/Paschalis/a96b2747ed85b8e5a796#file-crlib-c-L124" target="_blank">here</a>.</div> </div><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"></div> </div><div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks a lot for your help Pavel.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Cheers,</div><div class="gmail_default" style="font-family:verdana,sans-serif">Paschalis</div><br></div></div></div></div>