[Rcpp-devel] New Windows toolchain

Fri Mar 13 11:22:57 CET 2015

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