<br><br><div class="gmail_quote">On Tue, Jan 11, 2011 at 2:41 PM, Romain Francois <span dir="ltr"><<a href="mailto:romain@r-enthusiasts.com">romain@r-enthusiasts.com</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;">
Le 11/01/11 19:57, Romain Francois a écrit :<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Le 11/01/11 19:46, Douglas Bates a écrit :<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Tue, Jan 11, 2011 at 12:27 PM, Dominick<br>
Samperi<<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
On Tue, Jan 11, 2011 at 1:20 PM, Romain<br>
Francois<<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Le 11/01/11 19:12, Davor Cubranic a écrit :<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I think an important point from Doug has been lost in the subsequent<br>
20-odd messages of flamebombing:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I do not see this as compatible with the C++ Design principle we use<br>
whereby<br>
protection / unprotection occurs relative to the end of scope -- and<br>
not<br>
after every single assignment or allocation.<br>
<br>
In other words, gctorture() may well be a fine test for the C API<br>
and<br>
its<br>
PROTECT and UNPROTECT at every step but possibly not quite as<br>
much for<br>
Rcpp.<br>
</blockquote>
<br>
I don't think so. In the situation that Dominick is describing the C<br>
API is being used (calls to Rf_install, Rf_lang1, Rf_eval, ...) and<br>
you have to play by the rules of the C API. Essentially every time<br>
that you call a function in the C API that can cause a memory<br>
allocation you are open yourself to the possibility of having the<br>
garbage collector run and getting unprotected SEXPs blown away. And,<br>
naturally, Rf_eval can cause memory allocation.<br>
<br>
I understood Dominick to be saying that in the code related to<br>
Modules<br>
and the evaluator and all that which we have been trying to debug<br>
there are such cases of the use of the C API that are unsafe.<br>
</blockquote>
<br>
Can anyone comment whether this is correct?<br>
<br>
Davor<br>
</blockquote>
<br>
Yep. Doug's analysis is right. Rcpp is implemented with the C R API,<br>
and<br>
apparently there were a few places where we were not careful enough.<br>
Most<br>
notably in calls to Rf_lcons and Rf_cons. This has been partially<br>
dealt with<br>
today.<br>
</blockquote>
<br>
Just for the record, Doug is summarizing my analysis, based on several<br>
examples that I posted to this thread,<br>
and that I am pleased to see have inspired some remedial action.<br>
</blockquote>
<br>
Sorry for not responding earlier. I'm in the middle of teaching a<br>
short course.<br>
<br>
Dominick is correct that it was his analysis that picked up the<br>
failures to PROTECT/UNPROTECT in cases that were causing at least some<br>
of the problems with loading Modules. Credit where credit is due.<br>
<br>
As Romain has indicated, some of the problems have been fixed but<br>
apparently problems still remain. Debugging memory protection<br>
problems is often very difficult.<br>
</blockquote>
<br>
It is. Not sure what is my next step here. Remaining problems seem not<br>
directly related to Rcpp, but rather associated with lazy loading. See:<br>
</blockquote>
<br></div></div>
This now by not be related to Rcpp. See the thread on R-devel:<br>
<a href="http://comments.gmane.org/gmane.comp.lang.r.devel/26504" target="_blank">http://comments.gmane.org/gmane.comp.lang.r.devel/26504</a><br>
<br>
Please whoever is interested in fixing this, send your remarks and patches to the R-devel mailing list.<br></blockquote><div><br>This looks like the same problem that appeared in Rcpp, an unprotected SEXP in<br><R>/src/main/envir.c, in the function do_as_environment(), case VECSXP of the<br>
switch. Here is modified code that seems to fix the problem, at least under Linux:<br><br> case VECSXP: {<br> Rprintf("VECSXP as.environment\n");<br> /* implement as.environment.list() {isObject(.) is false for a list} */<br>
SEXP sp = PROTECT(lang4(install("list2env"), arg,<br> /*envir = */R_NilValue, /* parent = */R_EmptyEnv));<br> SEXP res = eval(sp, rho);<br> UNPROTECT(1);<br> return res;<br> }<br><br>
Dominick<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;"><font color="#888888">
<br>
Romain</font><div class="im"><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></div><div><div></div><div class="h5">
_______________________________________________<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>
</div></div></blockquote></div><br>