[Rcpp-devel] "Error during wrapup"
Romain Francois
romain at r-enthusiasts.com
Wed May 28 21:44:28 CEST 2014
(now with some links):
Le 28 mai 2014 à 16:31, John Mous <john.mous0 at gmail.com> a écrit :
> The object really is just built as part of the return statement. i.e. the lines from my prior e-mail exist as-is in the full code,
Sure. What happens is that Rcpp::export generates something that calls wrap( std::map<std::string,int> ).
> there's just more that actually builds the variables X1-X4 beforehand.
It should not be relevant.
> So I'm not sure where to debug from the client side. I'm a C/C++ developer, but have no experience with Rcpp internals or the general interface between R and C. I can insert some debug statements on the Rcpp side if you can guide me to where wrap is defined.
well wrap is defined here:
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28
It then performs a series of dispatch, that eventually lead to something that handles std::map<std::string,int>:
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255
template <typename InputIterator, typename T>
inline SEXP range_wrap_dispatch___impl__cast( InputIterator first, InputIterator last, ::Rcpp::traits::false_type ){
size_t size = std::distance( first, last ) ;
const int RTYPE = ::Rcpp::traits::r_sexptype_traits<typename T::second_type>::rtype ;
Shield<SEXP> x( Rf_allocVector( RTYPE, size ) );
Shield<SEXP> names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_type<RTYPE>::type CTYPE ;
CTYPE* start = r_vector_start<RTYPE>(x) ;
size_t i =0;
std::string buf ;
for( ; i<size; i++, ++first){
start[i] = (*first).second ;
buf = (*first).first ;
SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ;
}
::Rf_setAttrib( x, R_NamesSymbol, names ) ;
return wrap_extra_steps<T>( x ) ;
}
what I suspect to be the problem is this line:
::Rf_setAttrib( x, R_NamesSymbol, names ) ;
> What Romain says makes sense to me, despite my lack of expertise in this area.. the really intermittent nature of the problem and the fact that I can't recreate it in a small / fast running example suggests that perhaps this manifests when R happens to garbage collect at an unfortunate time (if I understood correctly). Thanks again.
Something like that. as hadley hinted, please try this under gc torture, or preferably through a debugger.
> On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 28 May 2014 at 10:02, John Mous wrote:
> | Hmm, unfortunately the GitHub version failed also.
>
> Darn.
>
> | The attributes on the failed
> | object are a little different though, here's what they look like:
> |
> | Browse[1]> str(results)
> | atomic [1:4] 1 1 2270 0
> | - attr(*, "")= symbol sim
> | - attr(*, "value")= promise to NULL
>
> I am not sure what we can do without a reproducible example. :-/
> The code just got a review / refreshment over the last few months.
>
> You best bet may the slow and tedious insertion of debug statements to see
> when / if the object changes.
>
> Dirk
>
> --
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>
> _______________________________________________
> 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/20140528/15eb3774/attachment-0001.html>
More information about the Rcpp-devel
mailing list