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-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