<br><br><div class="gmail_quote">On Sun, Jan 9, 2011 at 8:02 AM, 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 class="im">On Sun, Jan 9, 2011 at 12:45 AM, Dominick Samperi <<a href="mailto:djsamperi@gmail.com">djsamperi@gmail.com</a>> wrote:<br>
> Doug,<br>
><br>
> I think the problem is resolved. I wasted a lot of time trying to debug the<br>
> new<br>
> Module code, and didn't think to try gctorture() with older code that has<br>
> worked<br>
> for a long time. That code failed too!<br>
><br>
> The attached file tortureFix.cpp shows the kind of fix that is needed in<br>
> some of the Rcpp code, for example, in Reference.cpp, and perhaps in<br>
> other files. The attached script torture.R tests this function with/without<br>
> the suggested fix.<br>
><br>
> The unsafe code may or may not fail for you. It depends on the<br>
> machine/compiler, but because it can fail it is wrong. It fails consistently<br>
> under Windows using Visual C++, for example, which is a good reason<br>
> why software should be tested using compilers other than GCC, and testing<br>
> with gctorture() is obviously a good idea as well.<br>
<br>
</div>I was filled with hope that it would work to PROTECT all those<br>
instances of creating a call, then UNPROTECTing after evaluation. I<br>
think I got them all but my modified version still fails at the same<br>
point.<br>
<br>
> library(Uniform)<br>
Loading required package: Rcpp<br>
> gctorture(TRUE)<br>
> Rcpp:::.getModulePointer(unif_module)<br>
Before the evaluation in Evaluator::run, call is<br>
rcpp_tryCatch(evalq(new("C++Field"), <environment>))<br>
After the evaluation in Evaluator::run<br>
Error in list(c(76904L, 80L),<br>
"/home/bates/R/x86_64-pc-linux-gnu-library/2.12/Rcpp/R/Rcpp.rdb",<br>
<div class="im">TRUE, function (n) :<br>
unused argument(s)<br>
</div>("/home/bates/R/x86_64-pc-linux-gnu-library/2.12/Rcpp/R/Rcpp.rdb",<br>
TRUE, function (n)<br></blockquote><div><br>This is the same error message you get if you do not apply the<br>PROTECTION fixes, so the remaining problem may be of the<br>same nature, but perhaps not as transparent...<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>
This is in Evaluator::run where after the evaluation when the error<br>
code is being retrieved.<br>
<br>
I agree that any SEXP that gets created should be PROTECTed and<br>
appreciate your efforts in helping to debug this.<br>
<br>
I am trying a slightly different approach for the installation of the<br>
error indicator and codes from rcpp_tryCatch.<br>
<div><div></div><div class="h5"><br>
> On Sat, Jan 8, 2011 at 2:06 PM, Douglas Bates <<a href="mailto:bates@stat.wisc.edu">bates@stat.wisc.edu</a>> wrote:<br>
>><br>
>> On Sat, Jan 8, 2011 at 12:57 PM, Dominick Samperi <<a href="mailto:djsamperi@gmail.com">djsamperi@gmail.com</a>><br>
>> 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>><br>
>> > 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>><br>
>> >> wrote:<br>
>> >> > On Sat, Jan 8, 2011 at 12:45 AM, Dominick Samperi<br>
>> >> > <<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)<br>
>> >> >> 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)<br>
>> >> >> 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<br>
>> >> >> happens<br>
>> >> >> when<br>
>> >> >> gctorture() is turned on, so R must be clobbering an unprotected<br>
>> >> >> 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<br>
>> > 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<br>
>> > twice<br>
>> > at start-up, which does not seem right, but suppressing the second<br>
>> > attempt<br>
>> > does not fix the problem.<br>
>><br>
>> 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>
>><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>
>><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<br>
>> >> >>> 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<br>
>> >> >>>>>> of<br>
>> >> >>>>>> an<br>
>> >> >>>>>> "infelicity" in the Rcpp module code but the lme4a package,<br>
>> >> >>>>>> which<br>
>> >> >>>>>> now<br>
>> >> >>>>>> uses Rcpp modules extensively, ends up with some<br>
>> >> >>>>>> difficult-to-trace<br>
>> >> >>>>>> memory corruption issues. Yesterday i finally bit the bullet<br>
>> >> >>>>>> and<br>
>> >> >>>>>> ran<br>
>> >> >>>>>> a test with gctorture(TRUE) and valgrind enabled. It takes a<br>
>> >> >>>>>> 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<br>
>> >> >>>>>> 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<br>
>> >> >>>>> 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<br>
>> >> >>>> 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>
>> >> >>><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>
><br>
><br>
</div></div></blockquote></div><br>