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

[Laurent Gautier]

2008/7/16 Jeffrey Horner <jeff.horner at vanderbilt.edu>:
> Laurent Gautier wrote on 07/16/2008 08:02 AM:
>>
>> 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 problem is a program crash without saving data. Stack overflow is
> usually caused by either infinite recursion or very large stack (i.e. local)
> variables.

I think that R limits the number of recursions by checking how nested
an evaluation is.

> I've always disabled stack checking in rapache, and I never knew why the
> checking was added to R, but again wikipedia has merit:
>
> http://en.wikipedia.org/wiki/Stack_overflow
>
> Jeff
>
>>
>> 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.
>>
>> I looked around, and the JRI (Java/R Interface) is just disabling
>> stack checking for example.
>>
>>
>> Thanks,
>>
>>
>> Laurent
>>
>>
>> 2008/6/30 Laurent Gautier <lgautier at gmail.com>:
>>>
>>> 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --
> http://biostat.mc.vanderbilt.edu/JeffreyHorner
>