<br><br><div class="gmail_quote">On Sat, Jan 8, 2011 at 2:06 PM, Douglas Bates <span dir="ltr"><<a href="mailto:bates@stat.wisc.edu">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><div></div><div class="h5">On Sat, Jan 8, 2011 at 12:57 PM, Dominick Samperi <<a href="mailto:djsamperi@gmail.com">djsamperi@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sat, Jan 8, 2011 at 9:48 AM, Douglas Bates <<a href="mailto:bates@stat.wisc.edu">bates@stat.wisc.edu</a>> wrote:<br>
>><br>
>> On Sat, Jan 8, 2011 at 7:49 AM, Douglas Bates <<a href="mailto:bates@stat.wisc.edu">bates@stat.wisc.edu</a>> wrote:<br>
>> > On Sat, Jan 8, 2011 at 12:45 AM, Dominick Samperi <<a href="mailto:djsamperi@gmail.com">djsamperi@gmail.com</a>><br>
>> > wrote:<br>
>> >> I checked things under Linux and Windows (using GCC and VC++ DLL's) and<br>
>> >> the<br>
>> >> same problem occurs at the same place, which is a good sign when it<br>
>> >> comes to<br>
>> >> memory issues. Basically, the Rcpp::Reference(std::string) constructor<br>
>> >> that<br>
>> >> is<br>
>> >> part of S4_field, or S4_CppOverloadedMethods constructors fails,<br>
>> >> depending<br>
>> >> on<br>
>> >> which comes first (whether there are fields or not). This only happens<br>
>> >> 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>
>> 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>
><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<br>
> 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></div>The second call was eliminated in the SVN archive a couple of days<br>
ago. I have gotten around some of the problems with the garbage<br>
collection by redefining how the Rcpp_cache variable is created (not<br>
yet checked in) so it progresses further. I still think that there is<br>
a point where a promise in not being evaluated before being used but<br>
haven't found it yet.<br></blockquote><div><br>Gabor brought up the topic of Promises a few days ago and it<br>seems support for this is still in flux, and the current behavior is<br>to always to evaluate when a promise is detected, but perhaps some<br>
are missed, as you suggest.<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;">
<br>
With lazyLoad enabled the first time that you find a variable in the<br>
namespace it will have a PROMSXP typeof field and you need to invoke<br>
Rf_eval on it to actually get the value. There are several variables<br>
from the Rcpp namespace being used here, which is why I am suspicious<br>
that an unevaluated promise is somehow getting used.<br></blockquote><div><br>I gather from this that you have resolved the gctorture()/no-gctoture()<br>issues with your garbage collection fix? Otherwise, I don't see how<br>
unevaluated Promises would lead to problems that change with<br>the gctorture() status.<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 class="h5"><br>
>><br>
>> >> On Fri, Jan 7, 2011 at 9:47 AM, Romain Francois<br>
>> >> <<a href="mailto:romain@r-enthusiasts.com">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">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<br>
>> >>>>>> an<br>
>> >>>>>> "infelicity" in the Rcpp module code but the lme4a package, which<br>
>> >>>>>> now<br>
>> >>>>>> uses Rcpp modules extensively, ends up with some difficult-to-trace<br>
>> >>>>>> memory corruption issues. Yesterday i finally bit the bullet and<br>
>> >>>>>> 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<br>
>> >>>>>> package.<br>
>> >>>>>> I enclose the transcript. I should say that this is using<br>
>> >>>>>> 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)<br>
>> >>>>>> 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<br>
>> >>>>> 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<br>
>> >>>>> 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">Rcpp-devel@lists.r-forge.r-project.org</a><br>
>> >>><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>
><br>
><br>
</div></div></blockquote></div><br>