I believe the new toolchain uses SJLJ and not SEH specifically for backwards compatibility.
Avi On Thu, Mar 12, 2015 at 4:24 PM, JJ Allaire <jj.alla...@gmail.com> wrote: > Just a note that Rf_error is actually not technically allowed in Rcpp > (it's a longjmp which bypasses all C++ destructors on the stack). We > do it as follows: > > Rcpp::stop("error message") > > Which throws an exception which is ultimately caught by our wrapper > macro (which then calls Rf_error in a context where there are no more > destructors). > > > > On Thu, Mar 12, 2015 at 4:16 PM, Dirk Eddelbuettel <e...@debian.org> wrote: > > > > Duncan, > > > > The preferred and widely-documented address for Rcpp issues is rcpp-devel > > where I am forwarding this, I would appreciate keeping follow-up there. > > > > On 12 March 2015 at 15:11, Duncan Murdoch wrote: > > | Jack (and Dirk): > > | > > | I see this as well when I recompile Rcpp. > > | > > | Dirk: We're seeing the Rgui console on Windows lock up in 64 bit > > | Windows with a program calling Rf_error from Rcpp, but not from a > simple > > | C program (attached) that looks equivalent. This is using the new > > | toolchain, both to compile Rcpp and Jack's cppFunction() call below. > > | > > | I'd be happy to help with debugging this, but not for a few days: I'll > > | be out of the office until Wednesday next week, and I don't have 64 bit > > | Windows when I'm on the road. > > > > Sure. We can pick this up when you are back. The change vector appears > to > > be on your side of the fence so we need access from your end. Few of us > (on > > the Rcpp core group) use Windows all that much. > > > > I think I saw a blog post mentioned where someone said that with g++ > 4.9.2 > > (though possibly a different build/configuration/...) some > exception-related > > behaviour was improved. I am sure that something is different now, and > we > > will try to accomodate it. > > > > Safe travels. > > > > Dirk > > > > | > > | Duncan Murdoch > > | > > | On 12/03/2015 2:54 PM, Duncan Murdoch wrote: > > | > On 12/03/2015 1:31 PM, Jack Wasey wrote: > > | > > Dear Duncan, > > | > > > > | > > I hope you don't mind me emailing you directly, rather than through > > | > > r-devel, since it seemed a very specific problem. I had just sent > an > > | > > email to the list when it crossed with yours saying you had > released a > > | > > new Rtools, so I pulled my r-devel email. I have a probable R, > > | > > possible Rcpp bug causing a hang with Rf_error("stop") after > showing > > | > > the error message, but only with 64 bit Rtools 3.3 (downloaded a > few > > | > > hours ago). > > | > > > > | > > I'm afraid my reproducible example uses Rcpp, but only for > > | > > compilation. I'm not adept enough to eliminate the Rcpp step > quickly, > > | > > but I hope it will be of use anyway. > > | > > > > | > > Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }") > > | > > doError() > > | > > > > | > > This causes a hang after showing the error message. Winbuilder > checked > > | > > my package "icd9" without problems in 32 bit R-devel, and both 32 > and > > | > > 64 bit R current. > > | > > > > | > > Not being sure whether this is an Rcpp or R bug (see also > > | > > https://github.com/RcppCore/Rcpp/issues/276), I hesitated to > report > > | > > this as a bug against R itself, but perhaps people more skilled > than > > | > > me can do this if indeed it is so. > > | > > > | > I see the same problem. I've just tried the equivalent as a simple C > > | > program, and it was fine. I will try compiling Rcpp and see if that > > | > fixes it; I wouldn't be surprised if the binary on CRAN was built > with > > | > the old compiler. > > | > > > | > Duncan Murdoch > > | > > > > | > > Best wishes, > > | > > Jack > > | > > > > | > > On Thu, Mar 12, 2015 at 1:17 PM, Duncan Murdoch > > | > > <murdoch.dun...@gmail.com> wrote: > > | > > > I've just uploaded a minor update (3.3.0.1957) to Rtools33, > adding the > > | > > > cygpath.exe utility. That utility converts between Windows > style paths like > > | > > > D:/Rtools and Cygwin style paths like /cygdrive/d/Rtools. It > may be useful > > | > > > in configuration files if your external library expects to find > gcc on the > > | > > > path, since Rtools no longer puts it there. Assuming you want > to use the > > | > > > Rtools toolchain, you can construct the path to the gcc > directory in your > > | > > > Makevars.win file as > > | > > > > > | > > > $(cygpath $(RTOOLS))gcc492_$(WIN)/bin > > | > > > > > | > > > (where RTOOLS and WIN are macros from RHOME/etc/*/Makeconf that > should > > | > > > already have been read.) > > | > > > > > | > > > Thanks to JJ Allaire for the prompting on this. > > | > > > > > | > > > Duncan Murdoch > > | > > > > > | > > > ______________________________________________ > > | > > > r-de...@r-project.org mailing list > > | > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > | > > > | > > | [DELETED ATTACHMENT test.c, plain text] > > > > -- > > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > _______________________________________________ > > 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 >
_______________________________________________ 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