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
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, John
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(*,
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
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
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
(now with some links):
Le 28 mai 2014 à 16:31, John Mous john.mo...@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
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.
Le 29 mai 2014 à 00:35, John Mous john.mo...@gmail.com 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
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
rom...@r-enthusiasts.com wrote:
Le 29 mai 2014 à 00:35, John Mous john.mo...@gmail.com a écrit :
No luck with gctorture on yet, but I
Hello,
I am passing back a very simple std::mapstd::string, int from Rcpp as
follows:
std::mapstd::string, int 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
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,
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
13 matches
Mail list logo
