Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

r

rcpp

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[["blabla"]] = 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
like image 999
Dr G Avatar asked Apr 01 '11 09:04

Dr G


1 Answers

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.

like image 161
Martin Morgan Avatar answered Nov 10 '22 04:11

Martin Morgan