This also does not crash (because the destructor has already run
before the longjmp):
#include <R.h>
#include <Rinternals.h>
#include <string>
extern "C" SEXP foo(SEXP bar) {
{
std::string str;
}
Rf_error("foobar");
return bar;
}
Kevin and I are investigating further now.
On Thu, Mar 12, 2015 at 4:51 PM, JJ Allaire <jj.alla...@gmail.com> wrote:
> This is a minimum case to reproduce the crash (no Rcpp involved
> *however* a C++ destructor being executed seems to be what triggers
> the crash):
>
> #include <R.h>
> #include <Rinternals.h>
>
> #include <string>
>
> extern "C" SEXP foo(SEXP bar) {
>
> std::string str;
>
> Rf_error("foobar");
> return bar;
> }
>
> If I remove the "std::string str" line then it doesn't crash.
>
> So it's something related to the interaction between longjmp and C++
> destructors...
>
> On Thu, Mar 12, 2015 at 4:39 PM, JJ Allaire <jj.alla...@gmail.com> wrote:
>> Just noticed that Rcpp::stop also causes a hang on 64-bit R so the
>> longjmp in the wrapper macro is having the same effect (good to be
>> clear that the destructors being bypassed wasn't the source of the
>> hang/crash)
>>
>>
>> On Thu, Mar 12, 2015 at 4:25 PM, Avraham Adler <avraham.ad...@gmail.com>
>> wrote:
>>> I believe the new toolchain uses SJLJ and not SEH specifically for backwards
>>> compatibility.
>>>
>>> Avi
>>>
>>> On Thu, Mar 12, 2015 at 4:24 PM, JJ Allaire <jj.alla...@gmail.com> wrote:
>>>>
>>>> Just a note that Rf_error is actually not technically allowed in Rcpp
>>>> (it's a longjmp which bypasses all C++ destructors on the stack). We
>>>> do it as follows:
>>>>
>>>> Rcpp::stop("error message")
>>>>
>>>> Which throws an exception which is ultimately caught by our wrapper
>>>> macro (which then calls Rf_error in a context where there are no more
>>>> destructors).
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2015 at 4:16 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
>>>> >
>>>> > Duncan,
>>>> >
>>>> > The preferred and widely-documented address for Rcpp issues is
>>>> > rcpp-devel
>>>> > where I am forwarding this, I would appreciate keeping follow-up there.
>>>> >
>>>> > On 12 March 2015 at 15:11, Duncan Murdoch wrote:
>>>> > | Jack (and Dirk):
>>>> > |
>>>> > | I see this as well when I recompile Rcpp.
>>>> > |
>>>> > | Dirk: We're seeing the Rgui console on Windows lock up in 64 bit
>>>> > | Windows with a program calling Rf_error from Rcpp, but not from a
>>>> > simple
>>>> > | C program (attached) that looks equivalent. This is using the new
>>>> > | toolchain, both to compile Rcpp and Jack's cppFunction() call below.
>>>> > |
>>>> > | I'd be happy to help with debugging this, but not for a few days: I'll
>>>> > | be out of the office until Wednesday next week, and I don't have 64
>>>> > bit
>>>> > | Windows when I'm on the road.
>>>> >
>>>> > Sure. We can pick this up when you are back. The change vector appears
>>>> > to
>>>> > be on your side of the fence so we need access from your end. Few of us
>>>> > (on
>>>> > the Rcpp core group) use Windows all that much.
>>>> >
>>>> > I think I saw a blog post mentioned where someone said that with g++
>>>> > 4.9.2
>>>> > (though possibly a different build/configuration/...) some
>>>> > exception-related
>>>> > behaviour was improved. I am sure that something is different now, and
>>>> > we
>>>> > will try to accomodate it.
>>>> >
>>>> > Safe travels.
>>>> >
>>>> > Dirk
>>>> >
>>>> > |
>>>> > | Duncan Murdoch
>>>> > |
>>>> > | On 12/03/2015 2:54 PM, Duncan Murdoch wrote:
>>>> > | > On 12/03/2015 1:31 PM, Jack Wasey wrote:
>>>> > | > > Dear Duncan,
>>>> > | > >
>>>> > | > > I hope you don't mind me emailing you directly, rather than
>>>> > through
>>>> > | > > r-devel, since it seemed a very specific problem. I had just sent
>>>> > an
>>>> > | > > email to the list when it crossed with yours saying you had
>>>> > released a
>>>> > | > > new Rtools, so I pulled my r-devel email. I have a probable R,
>>>> > | > > possible Rcpp bug causing a hang with Rf_error("stop") after
>>>> > showing
>>>> > | > > the error message, but only with 64 bit Rtools 3.3 (downloaded a
>>>> > few
>>>> > | > > hours ago).
>>>> > | > >
>>>> > | > > I'm afraid my reproducible example uses Rcpp, but only for
>>>> > | > > compilation. I'm not adept enough to eliminate the Rcpp step
>>>> > quickly,
>>>> > | > > but I hope it will be of use anyway.
>>>> > | > >
>>>> > | > > Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }")
>>>> > | > > doError()
>>>> > | > >
>>>> > | > > This causes a hang after showing the error message. Winbuilder
>>>> > checked
>>>> > | > > my package "icd9" without problems in 32 bit R-devel, and both 32
>>>> > and
>>>> > | > > 64 bit R current.
>>>> > | > >
>>>> > | > > Not being sure whether this is an Rcpp or R bug (see also
>>>> > | > > https://github.com/RcppCore/Rcpp/issues/276), I hesitated to
>>>> > report
>>>> > | > > this as a bug against R itself, but perhaps people more skilled
>>>> > than
>>>> > | > > me can do this if indeed it is so.
>>>> > | >
>>>> > | > I see the same problem. I've just tried the equivalent as a simple
>>>> > C
>>>> > | > program, and it was fine. I will try compiling Rcpp and see if that
>>>> > | > fixes it; I wouldn't be surprised if the binary on CRAN was built
>>>> > with
>>>> > | > the old compiler.
>>>> > | >
>>>> > | > Duncan Murdoch
>>>> > | > >
>>>> > | > > Best wishes,
>>>> > | > > Jack
>>>> > | > >
>>>> > | > > On Thu, Mar 12, 2015 at 1:17 PM, Duncan Murdoch
>>>> > | > > <murdoch.dun...@gmail.com> wrote:
>>>> > | > > > I've just uploaded a minor update (3.3.0.1957) to Rtools33,
>>>> > adding the
>>>> > | > > > cygpath.exe utility. That utility converts between Windows
>>>> > style paths like
>>>> > | > > > D:/Rtools and Cygwin style paths like /cygdrive/d/Rtools. It
>>>> > may be useful
>>>> > | > > > in configuration files if your external library expects to find
>>>> > gcc on the
>>>> > | > > > path, since Rtools no longer puts it there. Assuming you want
>>>> > to use the
>>>> > | > > > Rtools toolchain, you can construct the path to the gcc
>>>> > directory in your
>>>> > | > > > Makevars.win file as
>>>> > | > > >
>>>> > | > > > $(cygpath $(RTOOLS))gcc492_$(WIN)/bin
>>>> > | > > >
>>>> > | > > > (where RTOOLS and WIN are macros from RHOME/etc/*/Makeconf that
>>>> > should
>>>> > | > > > already have been read.)
>>>> > | > > >
>>>> > | > > > Thanks to JJ Allaire for the prompting on this.
>>>> > | > > >
>>>> > | > > > Duncan Murdoch
>>>> > | > > >
>>>> > | > > > ______________________________________________
>>>> > | > > > r-de...@r-project.org mailing list
>>>> > | > > > https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> > | >
>>>> > |
>>>> > | [DELETED ATTACHMENT test.c, plain text]
>>>> >
>>>> > --
>>>> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>>> > _______________________________________________
>>>> > 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
