Re: [PATCH 1/1] c/r: define s390-specific checkpoint-restart code (v3)

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> 
> 
> Serge E. Hallyn wrote:
> > Implement the s390 arch-specific checkpoint/restart helpers.  This
> > is on top of Oren Laadan's c/r code.
> > 
> > With these, I am able to checkpoint and restart simple
> > programs as per Oren's patch intro.  While on x86 I never had
> > to freeze a single task to checkpoint it, on s390 I do need
> > to.  That is a prereq for consistent snapshots (esp with
> > multiple processes) anyway so I don't see that as a problem.
> > 
> > I'm having a strange problem with libraries though.  If I link a
> > program with some extra libraries (-lm, -lcrypt, -lpthread,
> > whatever), then after restart, if I do a fprintf("%f), the program
> > segfaults.  Not linking with extra libraries beside libc, or not
> > doing a fprintf of a float, doesn't cause any segfaults after
> > restart.  ltrace and strace aren't helpful, and gdb says
> > that the restarted program faulted at __printf_fp@@GLIBC2.4.
> > objdump -d output shows no difference (of course, since this
> > is after linking), but mentions a __dso_handle which doesn't
> > look familiar compared to x86 output.  /proc/$$/maps looks
> > the same on original and restarted task too.  So I'm
> > flummoxed.
> 
> You can try to force a core-dump of memory contents (and registers)
> at the end of the checkpoint and just before resuming to user space
> in the restart. Then compare the two. This technique proved invaluable
> to debug c/r issues.

Good idea, will try that, thanks.

-serge