[Carpet] Error when recovering from a checkpoint file

[Ian Hinder]

On Thu, Aug 24, 2006 at 11:13:02PM -0500, Erik Schnetter wrote:
> On Aug 24, 2006, at 22:09:03, Ian Hinder wrote:
> 
> >So, if I understand correctly, the problem would only occur if a thorn
> >dynamically adjusts a parameter to include newline characters.  In
> >that case, the checkpointing and recovery code would corrupt the
> >parameter.  So the fix I suggested before (removing the newlines upon
> >checkpoint) would still work.
> 
> I don't think it is a good idea to change parameter values before  
> checkpointing.  Either CCTK_ParameterSet should not accept strings  
> with newlines, or the routine that encodes parameters for  
> checkpointing should be corrected.  I suggest the latter.

I think the question of whether parameters should be allowed to
contain newlines should be clarified.  Currently the behaviour is
confused.  They are accepted but silently converted when found in a
parameter file, but CCTK_ParameterSet allows them.  They are then
handled incorrectly for checkpointing and recovery.  Either they
should be allowed (and work consistently) (option 1) or they should be
disallowed (option 2).

Option 1 would mean the parameter file parser would need to be
modified so that the newlines were not removed, and we would have to
be careful that existing thorns were able to cope with newlines in
parameters.  Should they be treated just like white space?  e.g. if I
have

out_1dvars = "admbase::gxx admbase::kxx
admbase::kzz"

which currently works, would the output routine that parsed the
parameter understand the newline, given that previously it had been
removed?  These newlines would have to be escaped as you suggest for
checkpointing and recovery.  Option 2 would just need
CCTK_ParameterSet to reject parameters containing newlines, and
preferably the parameter file parser should throw a warning when it
finds such a parameter that the newline has been removed, and that
such parameters are depracated.

> The routine IOUtil_GetAllParameters encodes all parameters into a  
> single string.  I think it should encode strings differently.  It  
> appears that the output of this routine is supposed to be human  
> readable.  In this case, it could e.g. enclose strings in quotes and  
> escape quotes and non-printable characters according to the rules for  
> C strings.  The routine IOUtil_SetAllParameters would then need to  
> parse these strings.  (Just to be safe, it could also check whether  
> the assignment symbol "=" is really present.)

Yes - the current behaviour is a little bit too simplistic.

> Here is an interesting idea: At run time, set the otherwise harmless  
> parameter Cactus::cctk_run_title to the value
> 
> Some Title\nIO::out_dir = /home/someone/.ssh\nIO::parfile_name =  
> authorized_keys
> 
> Then checkpoint and recover...  Well, there are probably easier ways  
> to disable your account if you can modify parameters at run time...

And it's a good thing that we are not worried too much about security
bugs in Cactus...

-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder