On Thu, Jan 6, 2011 at 2:19 PM, Douglas Bates <ba...@stat.wisc.edu> wrote:
> In the continuing saga ...
>
> On Thu, Jan 6, 2011 at 12:57 PM, Douglas Bates <ba...@stat.wisc.edu> wrote:
>> On Thu, Jan 6, 2011 at 9:54 AM, Douglas Bates <ba...@stat.wisc.edu> wrote:
>>> On Wed, Jan 5, 2011 at 2:38 PM, Douglas Bates <ba...@stat.wisc.edu> wrote:
>>>> On Wed, Jan 5, 2011 at 2:15 PM, Douglas Bates <ba...@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.
>>>
>>> I was able to remove the call to init_Rcpp_cache in the .onLoad
>>> function in Rcpp/R/zzz.R and still run R CMD check Rcpp successfully.
>>> Unfortunately, even with this change loading the lme4a package fails
>>> when gctorture is turned on. Transcript enclosed. Looks like I get
>>> to learn more about the Module loading process.
>>
>> I'm still flailing away at this. It is one of those really messy
>> debugging situations in that I can't make it fail except on the test
>> of the full example and using both gctorture and valgrind.
>>
>> It appears that the .onLoad function in lme4a is failing when called
>> in loadNameSpace. The .onLoad function was
>>
>> .NameSpace <- environment()
>> .onLoad <- function(libname, pkgname)
>> {
>> ## For Matrix API change (Oct.2009) - silence the warning:
>> assign("det_CHMfactor.warn", FALSE, envir = Matrix:::.MatrixEnv)
>> mod <- Module("lme4")
>> populate(mod, .NameSpace)
>> }
>>
>> So it seems that either the call to Module() or the call to populate()
>> is failing and the tryCatch block in runHook() within loadNamespace()
>> is creating an error message. The call: and message: parts of the
>> error message are generated from the error condition object using
>> conditionCall() and conditionMessage(). To me it looks like the call
>> stack has gotten corrupted because there are no calls like that. The
>> form of the call seems to be that of lazyLoadDBfetch in
>> $R_SRC/src/library/base/R/lazyLoad.R, which is called in a most
>> mysterious way.
>>
>> If anyone can shed any light on this, I would appreciate it. I have
>> another gctorture/valgrind run underway in which I don't use .onLoad
>> but call Module and populate explicitly to see if I can track down
>> where it is going south. Suggestions welcome.
>
> If I disable the .onLoad function and call Module() and populate()
> after loading the package and with gctorture(TRUE) then I get a
> failure in the call to populate, with the same mysterious value of the
> call and the message
>
>> library(lme4a)
> Loading required package: Matrix
> Loading required package: lattice
>
> Attaching package: 'Matrix'
>
> The following object(s) are masked from 'package:base':
>
> det
>
> Loading required package: minqa
> Loading required package: Rcpp
> Loading required package: MatrixModels
>
> Attaching package: 'MatrixModels'
>
> The following object(s) are masked from 'package:Matrix':
>
> model.Matrix
>
>> gctorture(TRUE)
>> mod <- Module("lme4", "lme4a")
>> populate(mod, .GlobalEnv)
> Error in list(c(78682L, 78L),
> "/home/bates/R/x86_64-unknown-linux-gnu-library/2.13/Rcpp/R/Rcpp.rdb",
> TRUE, function (n) :
> unused argument(s)
> ("/home/bates/R/x86_64-unknown-linux-gnu-library/2.13/Rcpp/R/Rcpp.rdb",
> TRUE, function (n)
>
> Can someone who knows more about the Module code than I (meaning
> Romain or John) tell me if that call could originate from within
> populate? It seems highly unlikely to me but I can't rule it out.
>
> By the way, this was using Rcpp_0.9.0.2 which still has two calls to
> init_Rcpp_cache. I'll change that and see if it makes a difference.
As they say in this season of (American) football games, "on further
review" it looks as if that string might have originated in a PROMSXP.
This is definitely getting wierd.
>>>>> On Wed, Jan 5, 2011 at 11:55 AM, Douglas Bates <ba...@stat.wisc.edu>
>>>>> wrote:
>>>>>> This time with the enclosure :-)
>>>>>>
>>>>>> On Wed, Jan 5, 2011 at 11:52 AM, Douglas Bates <ba...@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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
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
