[Rcpp-devel] Rcpp bug (was: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib))

[Avraham Adler]

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.allaire at 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 <edd at 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.duncan at 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-devel at r-project.org mailing list
> > | > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > | >
> > |
> > | [DELETED ATTACHMENT test.c, plain text]
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20150312/7a250e39/attachment-0001.html>