On Mon, Feb 14, 2011 at 12:45 PM, Dirk Eddelbuettel <e...@debian.org> wrote: > > The new Rcpp 0.9.1 release is now on CRAN. The NEWS entry is below; more > details are in the ChangeLog. But in short, this is a mostly 'internal > fixes' release which addresses some issues in memory management which, while > not tripping up our (short ?) unit tests or common usage, caused trouble for > advanced Rcpp modules use and repeated memory allocation / deallocation. > Rcpp should now be a tad more robust in general. > > The memory bug bit Doug Bates repeatedly, and he put his head down and > debugged the issue. A number of changes in Rcpp (as well as in R-devel) > later, this looks much better and we owe a hearfelt Thank You! > > A big Thanks! also goes to Luke Tierney who out some new memory debugging > code into R-devel which the --enable-strict-barrier in R 2.13.0 (due in > April) will enable. I am a little unclear at this point which of these > changes from R-devel will make it into R 2.12.2 due in eleven days (and I > think the envir.c fix is in but the debugging code is not) but maybe Doug > will clarify.
Yes, the envir.c fix is in. As a bit of background, even folks in R-core didn't all realize that the Rf_eval function doesn't PROTECT its arguments (because it is called so frequently and often recursively) so a construction like Rf_eval(Rf_install("foo"), ...) can, if it happens to be the first time that the symbol "foo" is evaluated, cause a garbage collection to occur with unpleasant results if things in ... are not protected. Luke has added debugging code to R-devel (to be R-2.13.0) that, when enabled, looks at every SEXP before using it to determine if it is unprotected. Using this he discovered a couple of problems, one in envir.c, that were tripping us up when gctorture(1) was active. The unprotected object situation has been fixed in R-2.12.2 but the code to detect unprotected objects will be in R-2.13.0, not R-2.12.2. It is assumed that anyone who knows about that particular piece of debugging code is able to compile R-devel for themselves. > Cheers, Dirk > > > 0.9.1 2011-02-14 > > o A number of internal changes to the memory allocation / protection of > temporary objects were made---with a heartfelt "Thank You!" to both > Doug Bates for very persistent debugging of Rcpp modules code, and to > Luke Tierney who added additional memory allocation debugging tools > to R-devel (which will be in R 2.13.0 and may also be in R 2.12.2) > > o Removed another GNU Make-specific variable from src/Makevars in order > to make the build more portable; this was noticed on FreeBSD > > o On *BSD, do not try to compute a stack trace but provide file and > line number (which is the same behaviour as implemented in Windows) > > o Fixed an int conversion bug reported by Daniel Sabanes Bove on r-devel, > added unit test as well > > o Added unit tests for complex-typed vectors (thanks to Christian > Gunning) > > o Expanded the Rcpp-quickref vignette (with thanks to Christian Gunning) > > o Additional examples were added to the Rcpp-FAQ vignette > > > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel