[Rcpp-devel] New Windows toolchain

JJ Allaire jj.allaire at gmail.com
Fri Mar 13 11:29:15 CET 2015

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.


On Fri, Mar 13, 2015 at 6:22 AM, Henrik Singmann
<henrik.singmann at 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-bounces at lists.r-forge.r-project.org
> [mailto:rcpp-devel-bounces at 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.duncan at 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 at 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 at 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 at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

More information about the Rcpp-devel mailing list