<div dir="auto"><div>jfyi, lm working on the issue. once i manage to narrow down the real cause of it, will ping you.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 25, 2019, 22:55 Diyu Zhou <<a href="mailto:zhoudiyupku@gmail.com">zhoudiyupku@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You are welcome. Thank you all for your help and the wonderful tool: CRIU you<br>
have created!<br>
<br>
On Wed, Sep 25, 2019 at 11:23 AM Cyrill Gorcunov <<a href="mailto:gorcunov@gmail.com" target="_blank" rel="noreferrer">gorcunov@gmail.com</a>> wrote:<br>
><br>
> On Wed, Sep 25, 2019 at 09:24:11AM -0700, Diyu Zhou wrote:<br>
> > I think in the CRIU code, the fpu frame saving and restoring is only performed<br>
> > for the main thread. Other threads do not do that and thus cause the corruption.<br>
> ><br>
> > I did a few experiment with the CRIU code. I'm confident the floating<br>
> > point corruption occurs inside the function parasite_dump_thread_seized<br>
> > in criu/parasite-syscall.c. Specifically, I suspect the parasite code run<br>
> > by compel_run_in_thread(tctl, PARASITE_CMD_DUMP_THREAD) causes the floating<br>
> > point corruption. I added a return 0; before that function and the<br>
> > floating point corruption does not occur anymore.<br>
><br>
> Great, thanks! So you've narrowed down the bug. Will take a look, thanks!<br>
</blockquote></div></div></div>