I will say this first -- I can't copy/paste the error message from the screen, so it's being retyped. Errors might occur. SORRY. I've been experiencing some interesting stack warnings recently when moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 series. In particular, I'm getting warnings of "Error: C stack usage is too close to the limit" before segfaulting, and this wasn't happening under the 2.2.x series. Here's the question statement: (ONLY) In the situation where one is embedding R, is anyone else seeing this occur with recent (past 2 weeks) versions of R (both the 2.3.x and 2.4.x series)? (it doesn't happen in the non-embedded case for me, at least not recently -- there was an SVN version recently where I did get that behavior in the non-embedded case, but it was "fixed" before I had a chance to report). I'm still debugging it; hopefully will have a bug report while I'm on (working) vacation in the states next week. best, -tony blindglobe at gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).
On Tue, 11 Apr 2006, A.J. Rossini wrote:> I will say this first -- I can't copy/paste the error message from the > screen, so it's being retyped. Errors might occur. SORRY. > > I've been experiencing some interesting stack warnings recently when > moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 series. In > particular, I'm getting warnings of "Error: C stack usage is too close > to the limit" before segfaulting, and this wasn't happening under the > 2.2.x series. > > Here's the question statement: (ONLY) In the situation where one is > embedding R, is anyone else seeing this occur with recent (past 2 > weeks) versions of R (both the 2.3.x and 2.4.x series)?It is likely reporting a real problem that was not spotted in 2.2.1, and that in the embedded case the stack usage is higher that standalone. I am guessing this is Linux. If so, does the simple expedient of raising the stack limit (in the shell, before launching the application) help? (I have done so for a couple of uses of R, and had no more problem.) For Windows, the relevant stack limit is in the calling application, and that is likely to be too low (1Mb or 2Mb: the R front-ends use 10Mb).> (it doesn't happen in the non-embedded case for me, at least not > recently -- there was an SVN version recently where I did get that > behavior in the non-embedded case, but it was "fixed" before I had a > chance to report). > > I'm still debugging it; hopefully will have a bug report while I'm on > (working) vacation in the states next week.Is this actually a bug, or at least one in R? There are new tools like Cstack_info() that can help to track down excessive stack usage.> > best, > -tony > > blindglobe at gmail.com > Muttenz, Switzerland. > "Commit early,commit often, and commit in a repository from which we can easily > roll-back your mistakes" (AJR, 4Jan05).-- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tony. Just to eliminate things, is the host application in which R is being embedded doing anything with the stack, e.g. some lisp system playing with threads via manipulating the stack? D. A.J. Rossini wrote:> I will say this first -- I can't copy/paste the error message from the > screen, so it's being retyped. Errors might occur. SORRY. > > I've been experiencing some interesting stack warnings recently when > moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 series. In > particular, I'm getting warnings of "Error: C stack usage is too close > to the limit" before segfaulting, and this wasn't happening under the > 2.2.x series. > > Here's the question statement: (ONLY) In the situation where one is > embedding R, is anyone else seeing this occur with recent (past 2 > weeks) versions of R (both the 2.3.x and 2.4.x series)? > > (it doesn't happen in the non-embedded case for me, at least not > recently -- there was an SVN version recently where I did get that > behavior in the non-embedded case, but it was "fixed" before I had a > chance to report). > > I'm still debugging it; hopefully will have a bug report while I'm on > (working) vacation in the states next week. > > best, > -tony > > blindglobe at gmail.com > Muttenz, Switzerland. > "Commit early,commit often, and commit in a repository from which we can easily > roll-back your mistakes" (AJR, 4Jan05). > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel- -- Duncan Temple Lang duncan at wald.ucdavis.edu Department of Statistics work: (530) 752-4782 4210 Mathematical Sciences Building fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFEO94V9p/Jzwa2QP4RAnWGAJ91+pwjFx7glZB/AuwCCK+PqszxiQCdHhpf fKWDQNLmtApXBANkZAZ+NaE=34Sm -----END PGP SIGNATURE-----
On Apr 11, 2006, at 5:34 AM, A.J. Rossini wrote:> I've been experiencing some interesting stack warnings recently > when moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 > series. In particular, I'm getting warnings of "Error: C stack > usage is too close to the limit" before segfaulting, and this > wasn't happening under the 2.2.x series. > > Here's the question statement: (ONLY) In the situation where one > is embedding R, is anyone else seeing this occur with recent (past > 2 weeks) versions of R (both the 2.3.x and 2.4.x series)? >When embedding R, the stack base is set to -1 (which is almost certainly wrong) if R cannot find the stack base using some system method. I have just fixed the detection for OS X, so you shouldn't get that message there anymore. However, I was wondering why to not set it to something reasonable - even if we are not the main application, IMHO less harm is done setting it to something based on the current stack pointer than using -1. The status quo relies on the embedding application to set the stack base - I don't know if that's a good idea. Opinions? Cheers, Simon
Thomas Friedrichsmeier
2006-Apr-17 01:34 UTC
[Rd] Stack checking, core dumps, and embedding R
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