<br><br><div class="gmail_quote">On Sat, Jan 8, 2011 at 9:48 AM, Douglas Bates <span dir="ltr"><<a href="mailto:bates@stat.wisc.edu" target="_blank">bates@stat.wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Sat, Jan 8, 2011 at 7:49 AM, Douglas Bates <<a href="mailto:bates@stat.wisc.edu" target="_blank">bates@stat.wisc.edu</a>> wrote:<br>
> On Sat, Jan 8, 2011 at 12:45 AM, Dominick Samperi <<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>> wrote:<br>
>> I checked things under Linux and Windows (using GCC and VC++ DLL's) and the<br>
>> same problem occurs at the same place, which is a good sign when it comes to<br>
>> memory issues. Basically, the Rcpp::Reference(std::string) constructor that<br>
>> is<br>
>> part of S4_field, or S4_CppOverloadedMethods constructors fails, depending<br>
>> on<br>
>> which comes first (whether there are fields or not). This only happens when<br>
>> gctorture() is turned on, so R must be clobbering an unprotected SEXP<br>
>> somewhere...<br>
><br>
> Thanks, Dominick. I too have been working on tracking this down and<br>
> got to that point. If you follow a little further you will find that<br>
> it is the evaluation of the R function getCurrentErrorMessage in the<br>
> Rcpp::Evaluator::run method where things start to go bad, as far as I<br>
> can see. I hope to be able to isolate this today as I need a working<br>
> version of lme4a by tomorrow.<br>
<br>
</div>My current theory is that Rcpp_cache is being blown away by the<br>
garbage collector. Because we want this to be persistent I think the<br>
simplest thing to do is to assign it to a name like .Rcpp_cache in the<br>
namespace during the .onLoad function. I'll try that.<br></blockquote><div><br>I tested this theory by cutting out the Evaluator code and it appears that<br>the cache is not harmed by gctorture(). I suspect that the problem may<br>
be earlier in the chain of construction, either a SEXP that was not preserved,<br>or an aliasing problem. It appears that init_Rcpp_cache() is called twice<br>at start-up, which does not seem right, but suppressing the second attempt<br>
does not fix the problem.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div><br>
>> On Fri, Jan 7, 2011 at 9:47 AM, Romain Francois <<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hmm. I commited 2845 and 2846 today.<br>
>>><br>
>>> Anyway, if you see it also with 0.9.0 this means more detective work.<br>
>>><br>
>>> Le 07/01/11 15:05, Douglas Bates a écrit :<br>
>>>><br>
>>>> On Fri, Jan 7, 2011 at 5:34 AM, Romain Francois<br>
>>>> <<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>> wrote:<br>
>>>>><br>
>>>>> Le 05/01/11 18:52, Douglas Bates a écrit :<br>
>>>>>><br>
>>>>>> I don't know whether this is through error on my part or because of an<br>
>>>>>> "infelicity" in the Rcpp module code but the lme4a package, which now<br>
>>>>>> uses Rcpp modules extensively, ends up with some difficult-to-trace<br>
>>>>>> memory corruption issues. Yesterday i finally bit the bullet and ran<br>
>>>>>> a test with gctorture(TRUE) and valgrind enabled. It takes a very<br>
>>>>>> long time and results in a segfault when trying to load the package.<br>
>>>>>> I enclose the transcript. I should say that this is using Rcpp_0.9.0<br>
>>>>>> from CRAN, not the SVN version of Rcpp.<br>
>>>>>><br>
>>>>>> I just got these results this morning (it was running overnight) and<br>
>>>>>> haven't looked at the code in Module.cpp and cache.cpp yet. If it<br>
>>>>>> seems likely that the code is beyond me I can try to work out a<br>
>>>>>> simpler example that triggers the problem.<br>
>>>>><br>
>>>>> Hi Doug,<br>
>>>>><br>
>>>>> Sorry for the delay, I'm not fully operational yet.<br>
>>>>><br>
>>>>> All this might be related to some code I put in during holidays and did<br>
>>>>> not<br>
>>>>> have a chance to fully test.<br>
>>>>><br>
>>>>> Can you try with rev 2845 and let me know if you still see the problem.<br>
>>>>><br>
>>>>> Romain<br>
>>>><br>
>>>> Regrettably the problem persists with rev 2845 (which was from<br>
>>>> 2011-01-04, is that the one you meant?) but it is also present when<br>
>>>> using Rcpp_0.9.0<br>
>>><br>
>>><br>
>>> --<br>
>>> Romain Francois<br>
>>> Professional R Enthusiast<br>
>>> +33(0) 6 28 91 30 30<br>
>>> <a href="http://romainfrancois.blog.free.fr" target="_blank">http://romainfrancois.blog.free.fr</a><br>
>>> |- <a href="http://bit.ly/fT2rZM" target="_blank">http://bit.ly/fT2rZM</a> : highlight 0.2-5<br>
>>> |- <a href="http://bit.ly/gpCSpH" target="_blank">http://bit.ly/gpCSpH</a> : Evolution of Rcpp code size<br>
>>> `- <a href="http://bit.ly/hovakS" target="_blank">http://bit.ly/hovakS</a> : RcppGSL initial release<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Rcpp-devel mailing list<br>
>>> <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-project.org</a><br>
>>> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br>