chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or


From: Peter Bex
Subject: Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?
Date: Fri, 26 Feb 2016 16:25:09 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Feb 26, 2016 at 04:03:12PM +0100, address@hidden wrote:
> > These two probably need to be fixed before we can do a release.
> > The second was always broken but it might not have been such a big
> > deal because we never allocated as much on the stack(?).  The first
> > is new with argvectors.
> 
> Unless one operates with native threads, the stack can be considered
> "large enough" (IIRC, it even grows on demand on modern systems,
> up to certain limits, but that may be wrong)

Yeah, but the C_stack_check will raise an exception if it grows beyond
our arbitrarily defined soft limit.  See the Salmonella link in my mail.

> > Like I said, I'm a bit ill so this may all be just a fever dream, but
> > the proper solution eludes me.  A fix for 2) might involve collecting
> > all the possible function calls a generated function will perform and
> > then pre-allocating the av2 (but only when needed), and then checking
> > whether that would cause the stack to overflow.
> 
> Do you mean 1) here? Since a CPS-procedure will call only a limited
> amount of CPS functions (usually 1), this should be doable.

Yeah, I probably meant 1).  Alternatively, we may make the allocation of
the vector return a pointer into the C stack *or* into the temporary stack
depending on whether there's still room in the C stack.

Then, fill the argvector with arguments and either call the function or
call into the GC with the CPS closure just like we would do at the start
of the CPS function.  The disadvantage is that we'd be doing one more
stack check, the advantage is that when we call more CPS functions, we
don't need to be pessimistic by using the maximum of the argument counts.

> > A fix for 1), if I'm not mistaken, would be to swap the way the stack
> > checks are done: the C_demand and C_stack_probe should observe the
> > reserve, while C_stack_check1() should only look at the hard limit.
> 
> (2?) I'm not sure whether I'm following completely, but the reserve should
> probably respected in any case.

Yeah, but it should be consistently applied in both cases, I think.
Currently the stack probe/demand at the start of a CPS function doesn't
respect the reserve while the C_stack_check does respect it, causing
these spurious "stack overflow" errors.

> > Besides, I think C_stack_check1 looks too complicated; why does it
> > create the temporary *_sp variable?  Is that to avoid a pointer
> > overflow/underflow?  Couldn't it just do a check like this:
> >
> > if ((C_byte *)C_stack_pointer < ((C_byte *)C_stack_limit - 
> > C_STACK_RESERVE)) err;
> 
> I think this doesn't make much of a difference in terms of compilation.
> The C compiler should take care of this.

The code is a bit hairy to look at, especially since it's a multi-line
macro.  This suggestion was purely aesthetical.

Cheers,
Peter

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]