<div dir="ltr"><div>Hi everyone,<br><br>Thank for you sticking with the problem even though it is so hard to recreate. I believe I have solved it, but the solution is based on a workaround, and I believe there is still a problem in Rcpp. First, the problem is not limited to wrapping map objects. I changed the code to return a NumericVector and had the same issue, although perhaps it's funneled through the same wrap code down the line -- again I'm not really familiar with Rcpp internals. Second, I noticed the problem occurred only when I used R's random number generator and RNGScope; code using C++'s RNG worked fine. Third, with that information in hand, I ran across this thread: <a href="http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2013-May/005838.html">http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2013-May/005838.html</a>, which suggests that the order in which the destructor of the RNGScope object and the returned object fire can muck things up. Based on this idea, I changed things so the returned NumericVector is created before the RNGScope object, and the already existing object is populated before being returned. This appears to have fixed it.<br>
<br></div>This solution is good enough for my immediate problem. Unfortunately for helping you fix this in Rcpp, all of this was done in the original code. I still can't create a small reproducible example. The problem is really hard to recreate -- the code in question is used for numerical simulation and the function runs hundreds of thousands of times before failing. But perhaps this new information can help inspire someone. I will be away for a few weeks, but am happy to test patches on the original code (if someone is inspired) if it's helpful once I return.<br>
<div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 1:10 AM, Kevin Ushey <span dir="ltr"><<a href="mailto:kevinushey@gmail.com" target="_blank">kevinushey@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What OS are you running on (Mac, Linux, Windows)? I really can't tease<br>
this out (with Mac + clang) thus far.<br>
<br>
On Wed, May 28, 2014 at 9:56 PM, Romain Francois<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:romain@r-enthusiasts.com">romain@r-enthusiasts.com</a>> wrote:<br>
><br>
> Le 29 mai 2014 à 00:35, John Mous <<a href="mailto:john.mous0@gmail.com">john.mous0@gmail.com</a>> a écrit :<br>
><br>
> No luck with gctorture on yet, but I haven't run it for very long. It slowed<br>
> things down to a complete crawl, but maybe in the long run it can recreate<br>
> the problem faster than running the original code (about 12 hours, the<br>
> previous estimate of a day was too high), so this may still be worthwhile.<br>
><br>
> On a whim I did try changing the two instances of Shield to Armor this<br>
> morning (I was able to locate the code in wrap.h by digging around before I<br>
> saw your e-mail) and ran the original full code without gctorture on, and<br>
> the problem still persists.<br>
><br>
><br>
> Would not be enough, you'd also have to do:<br>
><br>
>> x = ::Rf_setAttrib( x, R_NamesSymbol, names ) ;<br>
><br>
><br>
> so that the result of setAttrib gets protected even if it is a new SEXP,<br>
> which AFAIU can happen with setAttrib.<br>
><br>
> But I'm not sure this is the problem.<br>
><br>
> Romain<br>
><br>
><br>
> On Wed, May 28, 2014 at 3:44 PM, Romain Francois <<a href="mailto:romain@r-enthusiasts.com">romain@r-enthusiasts.com</a>><br>
> wrote:<br>
>><br>
>> (now with some links):<br>
>><br>
>> Le 28 mai 2014 à 16:31, John Mous <<a href="mailto:john.mous0@gmail.com">john.mous0@gmail.com</a>> a écrit :<br>
>><br>
>> The object really is just built as part of the return statement. i.e. the<br>
>> lines from my prior e-mail exist as-is in the full code,<br>
>><br>
>><br>
>> Sure. What happens is that Rcpp::export generates something that calls<br>
>> wrap( std::map<std::string,int> ).<br>
>><br>
>> there's just more that actually builds the variables X1-X4 beforehand.<br>
>><br>
>><br>
>> It should not be relevant.<br>
>><br>
>> So I'm not sure where to debug from the client side. I'm a C/C++<br>
>> developer, but have no experience with Rcpp internals or the general<br>
>> interface between R and C. I can insert some debug statements on the Rcpp<br>
>> side if you can guide me to where wrap is defined.<br>
>><br>
>><br>
>> well wrap is defined here:<br>
>><br>
>> <a href="https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28" target="_blank">https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28</a><br>
>><br>
>> It then performs a series of dispatch, that eventually lead to something<br>
>> that handles std::map<std::string,int>:<br>
>><br>
>> <a href="https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255" target="_blank">https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255</a><br>
>><br>
>><br>
>> template <typename InputIterator, typename T><br>
>> inline SEXP range_wrap_dispatch___impl__cast( InputIterator first,<br>
>> InputIterator last, ::Rcpp::traits::false_type ){<br>
>>      size_t size = std::distance( first, last ) ;<br>
>>      const int RTYPE = ::Rcpp::traits::r_sexptype_traits<typename<br>
>> T::second_type>::rtype ;<br>
>>      Shield<SEXP> x( Rf_allocVector( RTYPE, size ) );<br>
>>      Shield<SEXP> names( Rf_allocVector( STRSXP, size ) ) ;<br>
>>      typedef typename ::Rcpp::traits::storage_type<RTYPE>::type CTYPE ;<br>
>>      CTYPE* start = r_vector_start<RTYPE>(x) ;<br>
>>      size_t i =0;<br>
>>      std::string buf ;<br>
>>      for( ; i<size; i++, ++first){<br>
>>              start[i] = (*first).second ;<br>
>>              buf = (*first).first ;<br>
>>              SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ;<br>
>>      }<br>
>>      ::Rf_setAttrib( x, R_NamesSymbol, names ) ;<br>
>>      return wrap_extra_steps<T>( x ) ;<br>
>> }<br>
>><br>
>><br>
>> what I suspect to be the problem is this line:<br>
>><br>
>>  ::Rf_setAttrib( x, R_NamesSymbol, names ) ;<br>
>><br>
>><br>
>> What Romain says makes sense to me, despite my lack of expertise in this<br>
>> area.. the really intermittent nature of the problem and the fact that I<br>
>> can't recreate it in a small / fast running example suggests that perhaps<br>
>> this manifests when R happens to garbage collect at an unfortunate time (if<br>
>> I understood correctly). Thanks again.<br>
>><br>
>><br>
>> Something like that. as hadley hinted, please try this under gc torture,<br>
>> or preferably through a debugger.<br>
>><br>
>> On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel <<a href="mailto:edd@debian.org">edd@debian.org</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On 28 May 2014 at 10:02, John Mous wrote:<br>
>>> | Hmm, unfortunately the GitHub version failed also.<br>
>>><br>
>>> Darn.<br>
>>><br>
>>> | The attributes on the failed<br>
>>> | object are a little different though, here's what they look like:<br>
>>> |<br>
>>> | Browse[1]> str(results)<br>
>>> |  atomic [1:4] 1 1 2270 0<br>
>>> |  - attr(*, "")= symbol sim<br>
>>> |  - attr(*, "value")= promise to  NULL<br>
>>><br>
>>> I am not sure what we can do without a reproducible example. :-/<br>
>>> The code just got a review / refreshment over the last few months.<br>
>>><br>
>>> You best bet may the slow and tedious insertion of debug statements to<br>
>>> see<br>
>>> when / if the object changes.<br>
>>><br>
>>> Dirk<br>
>>><br>
>>> --<br>
>>> Dirk Eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a> | <a href="http://dirk.eddelbuettel.com" target="_blank">http://dirk.eddelbuettel.com</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Rcpp-devel mailing list<br>
>> <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-project.org</a><br>
>> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a><br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Rcpp-devel mailing list<br>
> <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-project.org</a><br>
> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a><br>
</div></div></blockquote></div><br></div>