[Rcpp-devel] New Windows toolchain

[JJ Allaire]

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