growing process size in simulation

Peter Dalgaard BSA
12 Oct 2002 17:15:01 +0200

Luke Tierney <> writes:

> > Thanks for looking into this, Luke. Yes, I agree. Specifically, the
> > issue seems to be that we used to work off a static variable "buff"
> > and use realloc on that inside AllocBuffer if it was non-null. Now
> > we've put the variable inside a structure "buf->data" and still trying
> > to use the realloc'ing construct, but since "buf" (aka localData) is a
> > local variable, it gets NULL'ed every time deparse1WithCutoff() is
> > called ---> deparse1WithCutoff needs to clean up on the way out.
> > 
> Right.  Unfortunately the issue goes beyond deparse.c.
> R_AllocStringBuffer is also called in printutils.c, saveload.c,
> scan.c.  I'm not sure about printutils.c, but the others look like
> they have the same issue.  R_LoadFromFile in saveload.c looks like a
> particular pain to fix; perhaps moving the buffer allocation up one
> call level would work.  I can try to fix this later next week unless
> someone else gets there first.
> I wonder if there is something we could add to the QA tools that could
> have picked this up.

I've fixed the one in deparse.c now. I had a suspicion that there
might be other cases, so I tried to abstract it in the same spirit as
R_AllocStringBuffer. There's now an R_FreeStringBuffer, and I think a
straightforward rule for invoking it: The function that allocates the
pointer for the storage must call R_FreeStringBuffer before returning.

R_LoadFromFile has more than a dozen exit points, so you get to say
"R_FreeStringBuffer(data.buffer);" quite a few times, but I don't
think the pain extends beyond that.

   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (             FAX: (+45) 35327907
r-devel mailing list -- Read
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: