growing process size in simulation
Luke Tierney <luke@stat.uiowa.edu> 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 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._