On looking more closely at the output, I thought that the problem may arise in loading the Rcpp package because that is when the function init_Rcpp_cache() is evaluated. So I ran another test which was simply
gctorture(TRUE) library(Rcpp) run with -d valgrind. Unfortunately (well, at least from my point of view) that test didn't show any problems. I'm at a bit of a loss where to go on this. On Wed, Jan 5, 2011 at 11:55 AM, Douglas Bates <[email protected]> wrote: > This time with the enclosure :-) > > On Wed, Jan 5, 2011 at 11:52 AM, Douglas Bates <[email protected]> wrote: >> I don't know whether this is through error on my part or because of an >> "infelicity" in the Rcpp module code but the lme4a package, which now >> uses Rcpp modules extensively, ends up with some difficult-to-trace >> memory corruption issues. Yesterday i finally bit the bullet and ran >> a test with gctorture(TRUE) and valgrind enabled. It takes a very >> long time and results in a segfault when trying to load the package. >> I enclose the transcript. I should say that this is using Rcpp_0.9.0 >> from CRAN, not the SVN version of Rcpp. >> >> I just got these results this morning (it was running overnight) and >> haven't looked at the code in Module.cpp and cache.cpp yet. If it >> seems likely that the code is beyond me I can try to work out a >> simpler example that triggers the problem. >> > _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
