C++ exceptions are not generating proper condition objects

[jimhester]

In particular the call and cppstack elements are not being populated appropriately. Looks like this condition object is created from exception_to_r_condition. The same behavior exists on MacOS (clang) and Windows. I did not test Linux.

Steps to reproduce

download.file("https://github.com/RcppCore/rcpp-gallery/raw/gh-pages/src/2013-01-13-intro-to-exceptions.cpp", "2013-01-13-intro-to-exceptions.cpp")
Rcpp::sourceCpp("2013-01-13-intro-to-exceptions.cpp", embeddedR = FALSE)
str(tryCatch(takeLog(-1.0), error = function(e) e))
#> List of 3
#>  $ message : chr "Inadmissible value"
#>  $ call    : language eval(substitute(expr), envir, enclos)
#>  $ cppstack: NULL
#>  - attr(*, "class")= chr [1:4] "std::range_error" "C++Error" "error" "condition"

Session Info

R version 3.3.0 (2016-05-03)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.6 (El Capitan)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] tools_3.3.0 Rcpp_0.12.7

[eddelbuettel]

Thanks for filing this. I noticed that too in the (printed) value of call when exiting via Rcpp::stop() from some tests. Not sure when the regression got introduced. This used to work :-/

[jimhester]

Looks like ccb3259 was when this was introduced. The commit prior prints <std::range_error: Inadmissible value> as was expected.

However I am still a little unclear when the call and cppstack values should be populated, even in the prior commit (b50768d) they are both NULL regardless of where the exception comes from in C++ or R call stacks.

[kevinushey]

FWIW, the main calls that are used to construct the stack trace are here:

Rcpp/inst/include/Rcpp/exceptions.h

Lines 152 to 183 in 88ebc36

	inline SEXP make_condition(const std::string& ex_msg, SEXP call, SEXP cppstack, SEXP classes){
	Rcpp::Shield<SEXP> res( Rf_allocVector( VECSXP, 3 ) ) ;
	#ifndef RCPP_USING_UTF8_ERROR_STRING
	SET_VECTOR_ELT( res, 0, Rf_mkString( ex_msg.c_str() ) ) ;
	#else
	Rcpp::Shield<SEXP> ex_msg_rstring( Rf_allocVector( STRSXP, 1 ) ) ;
	SET_STRING_ELT( ex_msg_rstring, 0, Rf_mkCharLenCE( ex_msg.c_str(), ex_msg.size(), CE_UTF8 ) );
	SET_VECTOR_ELT( res, 0, ex_msg_rstring ) ;
	#endif
	SET_VECTOR_ELT( res, 1, call ) ;
	SET_VECTOR_ELT( res, 2, cppstack ) ;
	Rcpp::Shield<SEXP> names( Rf_allocVector( STRSXP, 3 ) );
	SET_STRING_ELT( names, 0, Rf_mkChar( "message" ) ) ;
	SET_STRING_ELT( names, 1, Rf_mkChar( "call" ) ) ;
	SET_STRING_ELT( names, 2, Rf_mkChar( "cppstack" ) ) ;
	Rf_setAttrib( res, R_NamesSymbol, names ) ;
	Rf_setAttrib( res, R_ClassSymbol, classes ) ;
	return res ;
	}
	inline SEXP exception_to_r_condition( const std::exception& ex){
	std::string ex_class = demangle( typeid(ex).name() ) ;
	std::string ex_msg = ex.what() ;
	Rcpp::Shield<SEXP> cppstack( rcpp_get_stack_trace() );
	Rcpp::Shield<SEXP> call( get_last_call() );
	Rcpp::Shield<SEXP> classes( get_exception_classes(ex_class) );
	Rcpp::Shield<SEXP> condition( make_condition( ex_msg, call, cppstack, classes) );
	rcpp_set_stack_trace( R_NilValue ) ;
	return condition ;
	}

With other stuff in https://github.com/RcppCore/Rcpp/blob/88ebc36c89789c035135ca9b35dcfb316d2bce94/src/barrier.cpp.

I recall that we did a bunch of crazy stuff around error, warning and message handling but had to roll it back as it broke the handling of Rcpp_eval() within some contexts. Maybe we need to restore some of the error handling / tracking code in Rcpp_eval()?

[eddelbuettel]

My memory is also fuzzy. I am also unclear whether we ever explicitly filled call and cppstack. Didn't we just catch and call R's error return function with an appropriate message?

[kevinushey]

It may be this commit that broke things: 454de74

Note that prior to this we had calls to the error recorder:

Rcpp/inst/include/Rcpp/api/meat/Rcpp_eval.h

Lines 80 to 90 in 1c90562

	// check for error
	if (error_occured()) {
	Shield<SEXP> current_error (rcpp_get_current_error());
	Shield<SEXP> conditionMessageCall (::Rf_lang2(conditionMessageSym, current_error));
	Shield<SEXP> condition_message (::Rf_eval(conditionMessageCall, R_GlobalEnv));
	evalCall->error_occurred = true;
	evalCall->error_message = std::string(CHAR(::Rf_asChar(condition_message)));
	} else {
	evalCall->error_occurred = false;
	evalCall->result = res;
	}

We probably need to restore these error-recording calls in Rcpp_eval() (it looks like I accidentally removed them).

[DaveHastie]

I fear this might not be behaving as expected again. Doesn't seem to be propagating the C++ error at all on my system. Am I missing something?

> require(Rcpp)
Loading required package: Rcpp
> download.file("https://github.com/RcppCore/rcpp-gallery/raw/gh-pages/src/2013-01-13-intro-to-exceptions.cpp", "2013-01-13-intro-to-exceptions.cpp")
trying URL 'https://github.com/RcppCore/rcpp-gallery/raw/gh-pages/src/2013-01-13-intro-to-exceptions.cpp'
Content type 'text/plain; charset=utf-8' length 3430 bytes
==================================================
downloaded 3430 bytes

> Rcpp::sourceCpp("2013-01-13-intro-to-exceptions.cpp", embeddedR = FALSE)
> str(tryCatch(takeLog(-1.0), error = function(e) e))
List of 2
 $ message: chr "c++ exception (unknown reason)"
 $ call   : language takeLog(-1)
 - attr(*, "class")= chr [1:3] "simpleError" "error" "condition"

> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] Rcpp_0.12.13

loaded via a namespace (and not attached):
[1] compiler_3.4.1 tools_3.4.1   
> 

[eddelbuettel]

I think we may be behind one update on that very Rcpp Gallery post. We just discussed this around here.

I think part of the story is that you either need to use Rcpp Attributes to get proper wrapping, or use the BEGIN_RCPP and END_RCPP macros by hand to add it.

[DaveHastie]

Thanks for the quick return, sorry for being slow but didn't really understand the reply. Are you saying that the gallery is out of date with how to do propagate C++ errors? Or that it isn't possible?

Tried to figure out by myself, but that gallery example already uses Rcpp attributes and using the BEGIN_RCPP macro instead of the try / catch resulted in identical behaviour. Sorry for not getting it.

[kevinushey]

Are you using the default system compiler, or the CRAN-provided LLVM toolchain?

I suspect you're running into toolchain issues and not Rcpp issues. Here's what I see when using the system toolchain:

> str(tryCatch(takeLog(-1.0), error = function(e) e))
List of 3
 $ message : chr "Inadmissible value"
 $ call    : language takeLog(-1)
 $ cppstack: NULL
 - attr(*, "class")= chr [1:4] "std::range_error" "C++Error" "error" "condition"

[DaveHastie]

Thanks Kevin. I'm using clang 4.0.0 as per CRAN page rather than the default macOS compiler. Actually using a higher version of gfortran (7.2.0) than the one on the 6.1 suggested, but assume that wouldn't have impact here.

Here is the output of the compile step for Rcpp (I've tried C++11 and C++14 as I am using C++11 features in my code).

/usr/local/clang4/bin/clang++ -std=gnu++14 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I"/Library/Frameworks/R.framework/Versions/3.4/Resources/library/Rcpp/include" -I/usr/local/include   -fPIC  -Wall -g -O2 -c RcppExports.cpp -o RcppExports.o

[kevinushey]

The issue will likely go away if you use the default system toolchain (which is honestly what I'd recommend).

[kevinushey]

That said, it looks like the original issue (no C++ stack available) is actually still present. :-/ (but at least when using the system toolchain you do get the correct exception message)

[kevinushey]

Sorry, I missed one bit -- you only get a C++ back trace if you throw an Rcpp exception, and that case does work as expected.

So I think this does come back to the CRAN LLVM toolchain not behaving as expected here.

[DaveHastie]

Thanks Kevin - just come back to it and you are exactly right. When I changed back to the system compiler, the error message propagates as expected. Thanks both for your help.