You can get more information about intermittent problems like this by
running R under valgrind and using gctorture(TRUE). It will run very
slowly, but valgrind will flag the first time you use memory that is
not currently allocated by new or malloc. Without valgrind you only
see a problem if the
Hi everyone,
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
What OS are you running on (Mac, Linux, Windows)? I really can't tease
this out (with Mac + clang) thus far.
On Wed, May 28, 2014 at 9:56 PM, Romain Francois
wrote:
>
> Le 29 mai 2014 à 00:35, John Mous a écrit :
>
> No luck with gctorture on yet, but I haven't run it for very long. It slowed
>
Le 29 mai 2014 à 00:35, John Mous a écrit :
> No luck with gctorture on yet, but I haven't run it for very long. It slowed
> things down to a complete crawl, but maybe in the long run it can recreate
> the problem faster than running the original code (about 12 hours, the
> previous estimate
No luck with gctorture on yet, but I haven't run it for very long. It
slowed things down to a complete crawl, but maybe in the long run it can
recreate the problem faster than running the original code (about 12 hours,
the previous estimate of a day was too high), so this may still be
worthwhile.
(now with some links):
Le 28 mai 2014 à 16:31, John Mous 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 ).
> 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
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, there's just more
that actually builds the variables X1-X4 beforehand. So I'm not sure where
to debug from the client side. I'm a C/C++ developer, but have no
experienc
This looks like a protection issue.
For whomever this makes sense to: From the code that wraps such object, i would
investigate the call to setAttrib.
Perhaps we are supposed to get the result of it and protect it.
So i would tend to use an Armor instead of a Shield.
Romain
Le 28 mai 2014
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(*
Hmm, unfortunately the GitHub version failed also. 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
On Tue, May 27, 2014 at 6:10 PM, Joh
Hi Kevin,
Thanks. I will give the GitHub version a try -- the error usually manifests
only after running for about a day or so, so it may take a while to do
that. Unfortunately I am having trouble creating a small reproducible
example -- a function with just the assignments as written in my previo
Hi John,
I think we may have tackled this in some of the latest fixes with the
version of Rcpp on GitHub. Can you try installing that version and
trying again? Ie, try
install.packages(devtools); devtools::install_github("RcppCore/Rcpp")
then try running your code again.
Alternatively, plea
Hello,
I am passing back a very simple std::map from Rcpp as
follows:
std::map result;
result["X1"] = X1;
result["X2"] = X2;
result["X3"] = X3;
result["X4"] = X4;
return wrap(result);
The keys are hardcoded as shown, and the values X1-X4 are ints. Almost
always everything works fine, however, ve
14 matches
Mail list logo
