[R] R crashing after successfully running compiled code

[Prof Brian Ripley]

On Wed, 31 Oct 2012, Duncan Murdoch wrote:

> On 12-10-30 11:13 PM, Adam Clark wrote:
>> I'm running R 2.15.1x64, though the same problem persists for 2.13.0x32 and
>> 2.13.0x64.
>> 
>> I am trying to run compiled C code using the .C convention. The
>> code compiles without problems, dynamically loads within the R
>> workspace with no problems, and even runs and gives correct results with
>> no problems.
>> 
>> However, R will randomly crash within a few minutes of successfully using
>> the compiled function.
>> 
>> For example, if I run my compiled function using:
>> dyn.load("mycfun.dll")
>> answer<-.C("mycfun", parameters...), I get a completely sensible
>> result that gets stored to "answer".
>> However, if I try to do too many things to "answer", the R exits
>> without warning.
>> I've tried dyn.unload in hopes that R would become stable afterwards, but
>> in this case using the function crashes R without fail.
>> 
>> Usually, I can either plot, or view, or save "answer" to a file - but never
>> take more than a single action before R exits. This does not appear to
>> depend on how long R has been open. Initially, I thought it was a bug in
>> the "inline" function, but I'm finding the same problem now that I'm using
>> the dynamically loaded file directly. I'm used to R being insanely stable,
>> and am somewhat mystified by this whole problem.
>> 
>> My next move is to learn the ".Call" convention, as I suspect that
>> my problem is related to my "C" function using memory that R doesn't
>> know is used. But - before I invest a while lot more time on this, I'd
>> like to know whether anybody things this is likely to solve the problem.
>> If not, I may just want to run my code entirely in C, and forget the
>> R problem.
>
> I think your C code has a bug in it.  The bug might go away when you rewrite 
> the function to work within the .Call convention, but it is probably easier 
> to find the bug and fix it with the current code.
>
> Things to look for:
>
> Are you fully allocating all arrays in R before passing them to C?  The C 
> code receives a pointer and will happily write to it, whether that makes 
> sense or not.
>
> Are you careful with your limits on vectors?  In R, a vector is indexed from 
> 1 to n, but the same vector in C is indexed from 0 to n-1.  If the C code 
> writes to entry n, that will eventually cause problems.

Using R-devel and the following new feature

     • There is a new option, options(CBoundsCheck=), which controls how
       .C() and .Fortran() pass arguments to compiled code.  If true
       (which can be enabled by setting the environment variable
       R_C_BOUNDS_CHECK to yes), raw, integer, double and complex
       arguments are always copied, and checked for writing off either
       end of the array on return from the compiled code (when a second
       copy is made).  This also checks individual elements of character
       vectors passed to .C().

       This is not intended for routine use, but can be very helpful in
       finding segfaults in package code.

makes checking these two points a lot easier.

> Are you allocating memory in your C code?  There are several ways to do that, 
> depending on how you want it managed.  If you do it one way and expect it to 
> be managed in a different way, you'll get problems.

If you can run your code under valgrind (see 'Writing R Extensions') 
you will usually get pointed to the exact cause.  But that's for 
Linux, and with some care MacOS X.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595