开发者

In R what are the common cases of this error: "Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'character'"

开发者 https://www.devze.com 2023-02-21 15:09 出处:网络
I\'m fighting with a strange problem in R. I use an old version of Rcpp to integrate R with some C++ (sadly upgrading is not an option!), the Rcpp I use is the old RccpTemplate one. However I doubt th

I'm fighting with a strange problem in R. I use an old version of Rcpp to integrate R with some C++ (sadly upgrading is not an option!), the Rcpp I use is the old RccpTemplate one. However I doubt the problem is in there.

I have some R code which runs fine most of the time, but on occasion (especially when processing a large amount of data) fails mysteriously with Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'character'

It always fails in list operations, e.g.:

res[["blabl开发者_运维知识库a"]] = r

But if I use options(error=recover) and attempt the same after the error, the assignment can be performed with no problems. The C++ only deals with numeric vectors and is actually far away in time an code from the assignments that fail.

So my vague question is: what are the most common causes of such behaviour? Bad memory? Bad objects (perhaps bad RcppResultSet)? I'm having troubles attacking this issue...

For completeness:

platform       i386-pc-solaris2.10
arch           i386
os             solaris2.10
system         i386, solaris2.10
status
major          2
minor          10.1
year           2009
month          12
day            14
svn rev        50720
language       R


This is coming from an error in C code, likely in a package that you are using (not R itself). Either the C code is written incorrectly and you only sometimes evaluate that code branch, or the C code is written incorrectly and it corrupts memory. Likely this requires a C debugger; I'm not sure about Solaris, but on Linux I'd create a script that reliably reproduces the error (this can take some work, but is an essential step) then do

R -d gdb
gdb> r # (r)un R
> ^C ## cntrl-C key, breaks into the debugger
gdb> b Rf_error # set breakpoint when error occurs; tab completion available
gdb> c # continue in R
> source("test-script.R") # [error occurs]
gdb> bt  # backtrace -- current call stack, from Rf_error entry
gdb> up  # move up the stack; use this to get to package C code

and then it's careful scrutiny of the code, especially looking for mis-use of PROTECT. See gdb help. I'd strongly suggest updating R and your packages, since bugs do get fixed and you're about to invest a significant amount of time in this.

0

精彩评论

暂无评论...
验证码 换一张
取 消