[Rcpp-devel] Loading a package using Rcpp Modules results in memory corruption

Douglas Bates bates at stat.wisc.edu
Wed Jan 5 21:38:52 CET 2011


On Wed, Jan 5, 2011 at 2:15 PM, Douglas Bates <bates at stat.wisc.edu> wrote:
> 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.

Perhaps Romain or Dirk could clarify for me when init_Rcpp_cache
should be called.  It appears to be getting called twice, once
explicitly in the .onLoad expression in Rcpp/R/zzz.R and once
implicitly by being part of the R_init_Rcpp function defined in
Rcpp/src/Module.cpp.  Is this intentional?  Should one or both of
those be a maybe_init() call?  I think as it stands the second call
will overwrite the contents created by the first call.

I'm kind of grasping at straws here but I think there might be a
problem with the cache being created when the Rcpp namespace is
attached and then called again when the Rcpp package is loaded in my
example.


> On Wed, Jan 5, 2011 at 11:55 AM, Douglas Bates <bates at stat.wisc.edu> wrote:
>> This time with the enclosure :-)
>>
>> On Wed, Jan 5, 2011 at 11:52 AM, Douglas Bates <bates at stat.wisc.edu> 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.
>>>
>>
>


More information about the Rcpp-devel mailing list