Re: [Rcpp-devel] (Very) rare segfault
That makes sense. No real reason not to use attributes anyway :) Le 21 août 2014 à 15:54, JJ Allaire 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 > 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 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 >> wrote: >> >> Le 21 août 2014 à 11:47, Gregor Kastner a écrit : >> >> > On Thu, 21 Aug 2014 11:34:23 +0200 >> > Romain Francois 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@lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> > ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] (Very) rare segfault
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 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 > wrote: > > Le 21 août 2014 à 11:47, Gregor Kastner a écrit : > > > On Thu, 21 Aug 2014 11:34:23 +0200 > > Romain Francois 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@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] (Very) rare segfault
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 wrote: > > Le 21 août 2014 à 11:47, Gregor Kastner a écrit > : > > > On Thu, 21 Aug 2014 11:34:23 +0200 > > Romain Francois 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@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] (Very) rare segfault
Le 21 août 2014 à 11:47, Gregor Kastner a écrit : > On Thu, 21 Aug 2014 11:34:23 +0200 > Romain Francois 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@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] (Very) rare segfault
On Thu, 21 Aug 2014 11:34:23 +0200 Romain Francois 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. Manual handling works perfectly. Best, /g ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] (Very) rare segfault
Le 20 août 2014 à 20:57, Gregor Kastner a écrit : > JJ> Yes, RNGScope isn't safe by itself. You can use it via attributes (and we > JJ> make sure to use it correctly) or you could use this pattern e.g. if you > JJ> are planning to return a NumericVector: > JJ> > JJ> NumericVector vec(20); // or whatever size, the important thing is > JJ> allocating the return SEXP before RNGScope > JJ> > JJ> RNGScope rngScope; > JJ> > JJ> // do your thing > JJ> > JJ> > JJ> return vec; JJ, care to explain this ? I don't follow. > OK thanks. That's definitely worth knowing. Might be a cause for trouble for > others too, especially since misuse (i.e. other ordering) doesn't seem to show > any effects in many cases. > > DE> RNGScope is not for for seed setting, it is for RNG 'state sanity'. See > DE> Section 6.3 of 'Writing R Extensions' -- worst case you can just call > DE> GetRNGstate() and PutRNGstate() by hand. Though we never had to > DE> recommend that yet. > > Yep, sorry for the misuse of language. And I do understand going back to > GetRNGstate() and PutRNGstate() is a bit old school; but I can definitely > confirm that it seems to be safer than resorting do the > constructor/destuctor magic. Compiler/Destructor is not magic. It is determinism. That's like feature #1 of C++. And BTW it is definitely safer than any manual handling. ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
