Hi Kevin, Sorry to step in here but I would like to draw your attention to my mail from yesterday pointing to the fact that there seem to be two issues right now.
1. The issue you mentioned which can be easily reproduced by running the following to lines in R-devel 64bit on Windows with the following lines: Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }") doError() 2. The issue I mentioned in my previous mail regarding RcppEigen which can be reproduced by installing RcppEigen from source on 32bit R-devel and running the following line from the unit tests to crash R: ##### code ##### install.packages("RcppEigen", type = "source") require(RcppEigen) data(trees, package="datasets") .Call("fastLm",cbind(1, log(trees$Girth)),log(trees$Volume), 2L,PACKAGE="RcppEigen") ##### end code ##### It seems to even be enough to install RcppEigen from source on 64-bit R-devel and then load/attach the package in 32bit R-devel to crash R. To say it more clearly, the difference between the two issues is that while the first does not appear on 32bit R-devel, the second does, and the other way round for 64-bit R-devel. I am sorry I cannot provide a more detailed analysis what the bug in issue 2 actually triggers, but it is perhaps interesting to see that the following line does not trigger it (in which only the last argument to fastLM was changed): .Call("fastLm",cbind(1, log(trees$Girth)),log(trees$Volume), 1L,PACKAGE="RcppEigen") I hope this issue can also be considered as I will refrain from submitting a (much needed) update of my package to CRAN as long as the check fails like this on 32bit Windows R-devel. Unless of course someone knows that the wrath of CRAN will not be triggered by this error (which I doubt). Cheers, Henrik --- Dr. Henrik Singmann PostDoc University of Zürich, Switzerland http://singmann.org -----Ursprüngliche Nachricht----- Von: rcpp-devel-boun...@lists.r-forge.r-project.org [mailto:rcpp-devel-boun...@lists.r-forge.r-project.org] Im Auftrag von Kevin Ushey Gesendet: Freitag, 13. März 2015 03:43 An: Duncan Murdoch Cc: rcpp-devel Betreff: Re: [Rcpp-devel] New Windows toolchain Hi Duncan, First off -- a _huge_ thanks for all the time and effort you've put into updating the toolchain on Windows. We understand that, effectively, your (and R-core)'s stake in updating the toolchain on Windows is quite a bit smaller than ours, since C++ support is not a governing priority in the maintenance and development of R. Those of us on the C++ / Rcpp side are very excited at the prospect of being able to develop R packages which leverage C++11 features and also work across the board on all the platforms used by R, and so the prospect of the toolchain being updated on Windows is very exciting. At the moment, our hope is that a combination of patches to Rcpp, and potentially a few small patches to the Rtools scripts (which we are happy to provide and test ourselves), will show that the updated toolchain is stable enough for use with R 3.2.0. A summary of the issue for anyone else on the list who hasn't followed the other threads follows: --- Many Rcpp client packages / C++-containing packages erroneously make calls directly to `Rf_error()`. Calling `Rf_error()` directly from C++ can result in undefined behaviour -- this is because calling `Rf_error()` will result in a `longjmp`, which bypasses the destructors of any objects on the stack (thereby potentially leaking memory, but in general, causing undefined behaviour). The simplest reproducible example (without Rcpp) demonstrating this problem, from JJ, is this: #include <R.h> #include <Rinternals.h> #include <string> extern "C" SEXP ouch() { std::string str; Rf_error("ouch"); return R_NilValue; } When calling `ouch()`, the object `str` is effectively leaked, and its destructor is never called, due to the longjmp invoked from `Rf_error()`. With the older Rtools toolchain, packages generally 'got away' with doing this -- perhaps certain objects were leaked, or destructors weren't run, but often this wasn't a show-stopper. This is no longer the case with the new toolchain -- here, our 'luck runs out' and we instead get stuck with an infinite loop / a crash, with (at least as I see) msvcrt attempting to repeatedly throw and unwind an exception following the `longjmp`. One proposal fix would for us on the Rcpp side is to simply provide our own `#define` that masks `Rf_error()` and instead calls R's `Rf_error()` in a safe way (as `Rcpp::stop()` does) -- this is likely to resolve the issue for 99% of the Rcpp client packages. Packages that call `Rf_error()` from C++ code otherwise would require patches; perhaps we could assist in providing patches for those packages if necessary as well. It is also possible that we could build the Rtools toolchain in such a way that the old behaviour is preserved -- this is somewhat less desirable, since we're still letting packages get away with doing the 'wrong' thing, but it is certainly better than 'breaking the world' as we do now. With some luck, this could be achieved with some small modifications to how the toolchain is configured on build, but we are definitely shooting in the dark there as we really have no idea what flags we might want to set. Many thanks, Kevin On Thu, Mar 12, 2015 at 4:52 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > I've told some of you privately that I'm basically not going to be > working on this again before next Wednesday, due to travel. The 3.2.0 > release process starts on Monday, and I will be travelling for all but > two weeks before the release, so there is very little time left for changes. > > So here's what I plan to do: > > By the end of next week I will decide on what toolchain to include in > Rtools. This will be based largely on what I hear from this group, > because the main advantage of the new toolchain is C++ support. > > I think there are 2 likely choices, with a third possible. We could > use the Rtools33 toolchain that is currently on CRAN. This appears > likely to require changes by C++ users. Alternatively, we could > revert to the previous toolchain, based on gcc 4.6.3. If we do > revert, we will be able to change for R 3.2.1, which is unscheduled, > but likely to appear in June, judging by past history. > > The 3rd possibility is that someone other than me makes small changes > to the toolchain (the scripts are on CRAN in > bin/windows/Rtools/scripts), and enough people test the resulting > chain so we have general agreement that the modification works. It > needs to be someone other than me, because I need to try it out in my > own tests, and that means I need to have it in hand by Wednesday, if > I'm going to decide by Friday. I will not build this into Rtools > before next Friday, so you'll need to distribute this by some other means. > > Duncan Murdoch > > > > > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-deve > l _______________________________________________ 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