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:[email protected]] > Sent: 9. ágúst 2009 22:30 > To: Kristján Valur Jónsson > Cc: Stefan Reich; [email protected] > 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 <[email protected]>: > > 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 <[email protected]>: > >> 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:[email protected]] > >>> Sent: 9. ágúst 2009 04:42 > >>> To: Kristján Valur Jónsson > >>> Cc: Stefan Reich; [email protected] > >>> Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short > >>> script > >>> > >>> 2009/8/8 Kristján Valur Jónsson <[email protected]>: > >>> > 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. > >> > >> > > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
