We think the second issue may be caused by Rtools linking against posix threads rather than win32 threads (which it did in previous versions). We will attempt to create a patched version of Rtools today that can be used to verify this.
J.J. On Fri, Mar 13, 2015 at 6:22 AM, Henrik Singmann <henrik.singm...@psychologie.uni-freiburg.de> wrote: > 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 _______________________________________________ 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