Stack checking, core dumps, and embedding R

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Stack checking, core dumps, and embedding R

A.J. Rossini
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

[hidden email]
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Brian Ripley
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
>
> [hidden email]
> 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,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

A.J. Rossini
On 4/11/06, Prof Brian Ripley <[hidden email]> wrote:

> 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.

I don't know yet if it's a bug in R; if I knew so, I would have
submitted an R bug report.  I noted the stack monitoring changes that
were made, and working through the logic in the code (I seem to recall
main.c, errors.c, and one other file), it "seemed" correct.

This is indeed under Linux.   I'm unable to get to "command submission
function"
as I was before, so I'll be "backtracking" tonight with an earlier
version of the code.   I will try the suggestions that Brian made, and
will report back later tonight.

If anyone else has success or problems with embedding with this series
of R (2.3.x, 2.4.x), I'd appreciate input.   Again, I'm not seeing
this with normal CLI operation of R at this point.

best,
-tony

[hidden email]
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Duncan Temple Lang
In reply to this post by A.J. Rossini
-----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
>
> [hidden email]
> Muttenz, Switzerland.
> "Commit early,commit often, and commit in a repository from which we can easily
> roll-back your mistakes" (AJR, 4Jan05).
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

- --
Duncan Temple Lang                    [hidden email]
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-----

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

A.J. Rossini
Yep, bingo.  That's what I'm thinking, too.  Except that it's supposed
to be protected at my end.

"Supposed to".


On 4/11/06, Duncan Temple Lang <[hidden email]> wrote:

> -----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
> >
> > [hidden email]
> > Muttenz, Switzerland.
> > "Commit early,commit often, and commit in a repository from which we can easily
> > roll-back your mistakes" (AJR, 4Jan05).
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> - --
> Duncan Temple Lang                    [hidden email]
> 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-----
>


--
best,
-tony

[hidden email]
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

A.J. Rossini
In reply to this post by Brian Ripley
On 4/11/06, Prof Brian Ripley <[hidden email]> wrote:

> 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.

Okay, using 2-2-patched, I'm fine.

Using 2-3-patched and R-devel, I'm not fine (stack warnings and segfaulting).

What is the precise incantation for setting the stack?   using
"--max-ppsize=N"    didn't seem to help my problem (for values of N of
5000, 25000, 50000 -- should I try others?)

(This is under SBCL, i.e. satisfying Duncan's conjectures -- as soon
as I fix a few things (i.e. undoing CommonLispStat/R's threading which
is a bit SBCL specific, I'll try under CLISP, ECL, and CMUCL to
verify/check).

best,
-tony

[hidden email]
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Thomas Lumley
On Tue, 11 Apr 2006, A.J. Rossini wrote:

> On 4/11/06, Prof Brian Ripley <[hidden email]> wrote:
>> 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.
>
> Okay, using 2-2-patched, I'm fine.
> Using 2-3-patched and R-devel, I'm not fine (stack warnings and segfaulting).

The 2.2.x series didn't have the stack checker -- it was added for 2.3.0
-- so you would expect the stack warnings to be limited to 2.3.x (though
not necessarily the segfaults)

>
> What is the precise incantation for setting the stack?   using
> "--max-ppsize=N"    didn't seem to help my problem (for values of N of
> 5000, 25000, 50000 -- should I try others?)

No, it's the C stack, not the R pointer protection stack.

With tcsh this is
   limits stacksize 50000
or ulimit with bash


  -thomas

Thomas Lumley Assoc. Professor, Biostatistics
[hidden email] University of Washington, Seattle

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Simon Urbanek
In reply to this post by A.J. Rossini
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Jeffrey Horner
Simon Urbanek wrote:

> 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  

My question may be unrelated, but I stumbled across it while trying to
understand the above problem. The following is from R-trunk r37731
src/unix/system.c in Rf_initialize_R() and is run when the os is neither
linux nor freebsd:

     if(R_running_as_main_program) {
     /* This is not the main program, but unless embedded it is
        near the top, 5540 bytes away when checked. */
     R_CStackStart = (uintptr_t) &i + 6000;
     }

This is run before we know which direction the stack grows:

     {
         int ii;
     /* 1 is downwards */
         R_CStackDir = ((uintptr_t)&i > (uintptr_t)&ii) ? 1 : -1;
     }

So, R_CStackStart is being set to the address of i (on the stack) plus
6000 bytes, an approximation to somewhere near the beginning of the
stack, but this presumes the stack grows down, right? What if it grows
up? Then shouldn't we subtract 6000 bytes?

> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Jeffrey Horner       Computer Systems Analyst         School of Medicine
615-322-8606         Department of Biostatistics   Vanderbilt University

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

A.J. Rossini
In reply to this post by Simon Urbanek
On 4/12/06, Simon Urbanek <[hidden email]> wrote:

> 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?

Ah...   I see what you mean, Simon, which would explain the stack #'s
I was popping out (I'd changed the warning which occurs when stack is
within 5% (?) of max, to show me what it was talking about -- also,
your point explains why this happens nearly immediately.

Thanks all, I'd forgotten about ulimits.
best,
-tony

[hidden email]
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Brian Ripley
In reply to this post by Simon Urbanek
On Tue, 11 Apr 2006, Simon Urbanek wrote:

> 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.

Setting it to -1 means stack checking is disabled, so _no_ harm is done.
The test is

     if(R_CStackLimit != -1 && usage > 0.95 * R_CStackLimit) {

in errors.c.

> 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?

Wrong premise, wrong conclusion.

--
Brian D. Ripley,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Brian Ripley
In reply to this post by Jeffrey Horner
On Tue, 11 Apr 2006, Jeffrey Horner wrote:

> Simon Urbanek wrote:
>> 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
>
> My question may be unrelated, but I stumbled across it while trying to
> understand the above problem. The following is from R-trunk r37731
> src/unix/system.c in Rf_initialize_R() and is run when the os is neither
> linux nor freebsd:
>
>     if(R_running_as_main_program) {
>     /* This is not the main program, but unless embedded it is
>        near the top, 5540 bytes away when checked. */
>     R_CStackStart = (uintptr_t) &i + 6000;
>     }
>
> This is run before we know which direction the stack grows:
>
>     {
>         int ii;
>     /* 1 is downwards */
>         R_CStackDir = ((uintptr_t)&i > (uintptr_t)&ii) ? 1 : -1;
>     }
>
> So, R_CStackStart is being set to the address of i (on the stack) plus
> 6000 bytes, an approximation to somewhere near the beginning of the
> stack, but this presumes the stack grows down, right? What if it grows
> up? Then shouldn't we subtract 6000 bytes?

Probably, but is 12000 bytes important (stack sizes are around 10Mb)?
Do you know of an R platform on which it grows up, BTW (I don't)?

--
Brian D. Ripley,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Brian Ripley
In reply to this post by Brian Ripley
On Wed, 12 Apr 2006, Prof Brian Ripley wrote:

> On Tue, 11 Apr 2006, Simon Urbanek wrote:
>
>> 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.
>
> Setting it to -1 means stack checking is disabled, so _no_ harm is done.
> The test is
>
>     if(R_CStackLimit != -1 && usage > 0.95 * R_CStackLimit) {
>
> in errors.c.
>
>> 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?
>
> Wrong premise, wrong conclusion.

Sorry, I misunderstood this (we don't use 'base'): I guess you mean if
R_CStackStart is unset, it defaults to -1.  In that case the intention was
that R_CStackLimit be set to -1.  It seems that has dropped off, and I
have reinstated it.

--
Brian D. Ripley,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

Thomas Lumley
In reply to this post by A.J. Rossini
On Tue, 11 Apr 2006, A.J. Rossini wrote:
>
> (This is under SBCL, i.e. satisfying Duncan's conjectures -- as soon
> as I fix a few things (i.e. undoing CommonLispStat/R's threading which
> is a bit SBCL specific, I'll try under CLISP, ECL, and CMUCL to
> verify/check).
>

Also, according to
   http://www.cyrusharmon.org/cl/blog/display/49
SBCL uses SIGSEGV as an internal signalling mechanism, which might
conflict with the new segfault catcher.

  -thomas

Thomas Lumley Assoc. Professor, Biostatistics
[hidden email] University of Washington, Seattle

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stack checking, core dumps, and embedding R

A.J. Rossini
I'm pretty sure that we've fixed that problem.  (I'm merging 2 different
CL/R trees together, one of which is Cyrus's).   An alternative fix patched
R to undo that, but that's not kosher.

best,
-tony



On 4/12/06, Thomas Lumley <[hidden email]> wrote:

>
> On Tue, 11 Apr 2006, A.J. Rossini wrote:
> >
> > (This is under SBCL, i.e. satisfying Duncan's conjectures -- as soon
> > as I fix a few things (i.e. undoing CommonLispStat/R's threading which
> > is a bit SBCL specific, I'll try under CLISP, ECL, and CMUCL to
> > verify/check).
> >
>
> Also, according to
>   http://www.cyrusharmon.org/cl/blog/display/49
> SBCL uses SIGSEGV as an internal signalling mechanism, which might
> conflict with the new segfault catcher.
>
>        -thomas
>
> Thomas Lumley                   Assoc. Professor, Biostatistics
> [hidden email]        University of Washington, Seattle
>



--
best,
-tony

[hidden email]
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can
easily
roll-back your mistakes" (AJR, 4Jan05).

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel