[Rcpp-devel] New Windows toolchain

[Kevin Ushey]

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