Re: [Rd] Embedded R, last errormessage, and stack smashing

[Simon Urbanek]

Laurent,

On Jul 16, 2008, at 9:02 AM, Laurent Gautier wrote:
The only way to overcome the problem I can find is to tweak the
R_CStackLimit with:

R_CStackLimit = (uintptr_t) -1;

The question I am having now is: what are the implications of doing
so, that is what are the potential problems ?


The implications are that you are disabling stack checks, i.e. R won't  
be able to detect stack overflows.


The R-extensions manual says: " Stack-checking can be disabled by  
seting R_CStackLimit = (uintptr_t)-1, but it is better to if  
possible set appropriate values. (What these are and how to  
determine them are OS-specific, and the stack size limit may differ  
for secondary threads. If you have a choice of stack size, at least  
8Mb is recommended.)"
I am not very sure of how an appropriate value can be determined.


You can have a look at R sources which do this - the basic idea (if no  
OS-specific method exists) is to fetch an address of a local variable  
which will be on the stack and then add as much space as the size of  
the stack is. On some systems there is an API to find the stack of the  
current thread. However, this works only if you guarantee that you'll  
be calling R from a specific thread (which is generally a good idea,  
though).


I looked around, and the JRI (Java/R Interface) is just disabling  
stack checking for example.


JRI is quite general and supports different use models - one allows R  
to be called from different threads (with appropriate care and  
synchronization), so it has no choice but to disable the check because  
the stack will change across threads.

Cheers,
Simon





2008/6/30 Laurent Gautier <[EMAIL PROTECTED]>:
Dear list,

I am having an embedded R, dying with
*** stack smashing detected *** in one specific case.

My code is such as I evaluate R expression with C code like

res = R_tryEval(expr, env, &error);

and in case of error, get the error message (usually sucessfully)  
with
code like below:

SEXP geterrmessage = findVar(install("geterrmessage"),  
R_BaseNamespace);
PROTECT(expr = allocVector(LANGSXP, 1));
SETCAR(expr, geterrmessage);
PROTECT(res = Rf_eval(expr, R_GlobalEnv));
// ---> *** stack smashing detected ***

The call to Rf_eval does not return as the stack smashing error  
stops the show.

Tracing with gdb where the problem occurs, I follow the path:
eval -> R_CheckStack in main/error.c -> errorcall in main/error.c


In errorcall, I narrow down the origin of the problem around the  
lines:
658    va_start(ap, format);
659    verrorcall_dflt(call, format, ap);
660    va_end(ap);
and add a breakpoint on each one of those lines.


My gdb session till the stack smashing crashing is then looking like:

Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
stack usage is too close to the limit")
  at errors.c:658
658         va_start(ap, format);
(gdb) p ap
$2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =  
0x41c22f60,
reg_save_area = 0x41c22e70}}
(gdb) p format
$3 = 0x7f4dbdc87698 "C stack usage is too close to the limit"
(gdb) continue
Continuing.

Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
stack usage is too close to the limit")
  at errors.c:659
659         verrorcall_dflt(call, format, ap);
(gdb) continue
Continuing.

Breakpoint 6, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406  
"%s")
at errors.c:648
648         if (R_ErrorHook != NULL) {
(gdb) continue
Continuing.

Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406  
"%s")
at errors.c:658
658         va_start(ap, format);
(gdb) continue
Continuing.

Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406  
"%s")
at errors.c:659
659         verrorcall_dflt(call, format, ap);
(gdb) continue
Continuing.
*** stack smashing detected ***: /usr/bin/python terminated


My understanding is that there is a C stack problem about to happen R
tries to report, but in the process of reporting it
causes a C stack-related crash. Is there something odd with R  
handling
the situation, or should I look for the cause
of the problem elsewhere ?

Thanks,


L.


______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel