[Rcpp-devel] (Very) rare segfault

[Romain Francois]

That makes sense. No real reason not to use attributes anyway :) 

Le 21 août 2014 à 15:54, JJ Allaire <jj at rstudio.com> a écrit :

> Yes, the link posted by Matteo is what provoked us to make the change in Rcpp Attributes to dance around the constructor/destructor issues. 
> 
> Net: If you are using attributes then this isn't a concern, if you are not then you need the return value SEXP on the stack prior to RNGScope.
> 
> On Thursday, August 21, 2014, Romain Francois <romain at r-enthusiasts.com> wrote:
> Ah interesting. PutRNGstate does indeed allocate so might trigger GC. 
> https://github.com/wch/r-source/blob/fbf5cdf29d923395b537a9893f46af1aa75e38f3/src/main/RNG.c#L437
> 
> That's a whole new Pandora's box right there. 
> 
> Le 21 août 2014 à 12:10, Matteo Fasiolo <matteo.fasiolo at gmail.com> a écrit :
> 
>> Hi Romain and Gregor,
>> 
>> maybe I am misunderstanding everything, but hasn't this problem been explained and solved here:
>> 
>> http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2013-May/005838.html
>> 
>> Best,
>> 
>> Matteo
>> 
>>  
>> 
>> 
>> On Thu, Aug 21, 2014 at 10:58 AM, Romain Francois <romain at r-enthusiasts.com> wrote:
>> 
>> Le 21 août 2014 à 11:47, Gregor Kastner <gregor.kastner at wu.ac.at> a écrit :
>> 
>> > On Thu, 21 Aug 2014 11:34:23 +0200
>> > Romain Francois <romain at r-enthusiasts.com> wrote:
>> >
>> > GK> Yep, sorry for the misuse of language. And I do understand going back to
>> > GK> GetRNGstate() and PutRNGstate() is a bit old school; but I can definitely
>> > GK> confirm that it seems to be safer than resorting do the
>> > GK> constructor/destuctor magic.
>> >>
>> >> Compiler/Destructor is not magic. It is determinism.
>> >>
>> >> That's like feature #1 of C++.
>> >
>> > agreed: s/magic/automagic/g
>> >
>> >> And BTW it is definitely safer than any manual handling.
>> >
>> > I cannot say that in the current case, as relying on the destructor does seem
>> > to create problems (in rare cases, making it even worse!) if objects which
>> > are to be returned are instantiated after the RNGScope object. Conditional on
>> > the fact the I understood JJ correctly, that is.
>> 
>> Then it's a bug in how constructor or destructor is implemented in this class, probably with the counter.
>> 
>> Or something invalidates the very assumptions of C++ here. Perhaps raw R api is called and the destructor is not called because of some long jump or something.
>> 
>> Without a repex anyway, it is hard to diagnose what's happening.
>> 
>> You're probably onto somthing, but going directly to the "destructor are not safe, I'll just use C function calls" is a dangerous route, soon you'll start using SEXP as you won't trust ctors/dtors of Rcpp objects do the right thing.
>> 
>> > Manual handling works perfectly.
>> >
>> > Best,
>> > /g
>> 
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140821/27e3d3d7/attachment.html>