[Rd] Stack checking, core dumps, and embedding R
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Mon Apr 17 03:34:09 CEST 2006
Dear R developers,
it seems the stack checking issue with embedded applications is not fully
resolved, yet. The problem arises, when multiple threads are involved. I.e.
the case, where R is run in a separate thread of the main application. In
this case, the call to (unix/system.c)
R_CStackStart = (uintptr_t) __libc_stack_end;
will set the stack start to the start of the main threads stack, while the
stack of the thread in which R is running may be entirely different. This
leads to a bad value of R_CStackStart, and subsequently R_CheckStack () is
likely to fail for no good reason.
I believe, a more robust solution would be to use
pthread_attr_t stack_addr;
pthread_attr_getstackaddr (pthread_self (), &stack_addr);
R_CStackStart = (uintptr_t) stack_addr;
probably with some #ifdefs around it. Of course that's somewhat ugly as well,
having to pull in the pthread-library for this purpose.
An easier solution might be to explicitely set
if (R_running_as_main_program) {
[...]
} else {
R_CStackStart = -1;
}
and thereby disable stack checking for all embedded cases.
Yet another solution, which I do not understand, why it is not being used
would be to always use the
R_CStackStart = (uintptr_t) &i + (6000 * R_CStackDir);
logic, not just when running as the main program, maybe with a slightly larger
margin for safety.
Finally, if all these are not desirable, I propose a heuristic check somewhat
like
if (abs (R_CStackStart - &i) > 20000) {
/* Very unlikely we're this far away from the stack start at this
point in the code. Disable checking */
R_CStackStart = -1;
}
Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20060417/c54a4a5d/attachment.bin
More information about the R-devel
mailing list