growing process size in simulation
Sat, 12 Oct 2002 09:49:21 -0500 (CDT)
On 12 Oct 2002, Peter Dalgaard BSA wrote:
> Luke Tierney <firstname.lastname@example.org> writes:
> > It looks to me like something in deparse (which gets called in
> > t.test.default) may be the culprit:
> > for(i in 1:100000) rval <- deparse("x")
> > exhibits the same behavior.
> > In running under gdb it looks like deparse("x") results in the call
> > sequence
> > deparse1WithCutoff->deparse2->deparse2buff->print2buff->R_AllocStringBuffer
> > and malloc is called in R_AllocStringBuffer to create the buffer. The
> > allocation is stored into a local structure variable in
> > deparse1WithCutoff and I think is not being free'd before
> > deparse1WithCutoff exits.
> 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.
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
241 Schaeffer Hall email: email@example.com
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: firstname.lastname@example.org