[Stackless] Stackless 2.6.2/Win crash with very short script

[Kristján Valur Jónsson]

Nesting levels might well be it, I don't know how they work, though.
However, when it attempts to soft switch into main, it notices that there is a "nesting level" and inserts a hard switching frame.  This is where the trouble starts.  I'll keep following it today.  
K

> -----Original Message-----
> From: Richard Tew [mailto:richard.m.tew at gmail.com]
> Sent: 9. ágúst 2009 22:30
> To: Kristján Valur Jónsson
> Cc: Stefan Reich; stackless at stackless.com
> Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short
> script
> 
> And my suspicion is that we changed something to do with nesting
> levels which fixed something else, and broke this by causing the soft
> switch instead of the a hard one.
> 
> 2009/8/10 Richard Tew <richard.m.tew at gmail.com>:
> > Sorry, by frame going away, I meant the exiting of the function call
> > which frees its locals including the channel.
> >
> > 2009/8/9 Kristján Valur Jónsson <kristjan at ccpgames.com>:
> >> Richard, I don't think this is it at all.  Blocking doesn't cause
> the frame to go away, and the frame doesn't get collected before the
> error occurrs.
> >> I think it is a simple malfunction in the soft-switching code.  The
> issue goes away if soft-switching is turned off.
> >> I'll have another go at it.
> >>
> >>> -----Original Message-----
> >>> From: Richard Tew [mailto:richard.m.tew at gmail.com]
> >>> Sent: 9. ágúst 2009 04:42
> >>> To: Kristján Valur Jónsson
> >>> Cc: Stefan Reich; stackless at stackless.com
> >>> Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short
> >>> script
> >>>
> >>> 2009/8/8 Kristján Valur Jónsson <kristjan at ccpgames.com>:
> >>> > I had a go at this today.
> >>> > It is a bug with soft-switching.  turning off soft switching
> makes
> >>> the problem go away.
> >>> > The issue happens when the tasklet blocks and the sheduler is
> >>> reviving main.  It decides to try soft switching but then inserts
> the
> >>> hard switching frame.  This is how far I got.
> >>> >
> >>> > Richard, I am very unfamiliar with soft switching so maybe you
> can
> >>> help me out with this in a private thread?
> >>>
> >>> This is the old problem I fixed years ago approaching from a
> different
> >>> angle.  It looks like some other change we have made has broken it
> in
> >>> a different way.  We should be hesitant we don't break something
> else
> >>> when we fix this.
> >>>
> >>> I don't have time to look further into this right now, especially
> >>> given that it is not a realistic use case that someone would
> encounter
> >>> in a deployed application.
> >>>
> >>> But my understanding of it is that a tasklet blocks on a channel
> that
> >>> was created within it.  This soft switches and the tasklet function
> >>> exits, causing garbage collection of the channel (because tasklets
> do
> >>> not hold references to channels they block on and the only
> reference
> >>> to the channel is the frame).  The garbage collection of the
> channel
> >>> with the only reference to the tasklet within it, means the tasklet
> is
> >>> also garbage collected.  So of course we hard switch to the
> tasklet,
> >>> despite the fact we are still effectively in it.
> >>>
> >>> I don't see an obvious fix to this.
> >>>
> >>> Cheers,
> >>> Richard.
> >>
> >>
> >