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

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