Ok, it turns out you are right. The problem is the Channel().receive(). When softswitching, receive() returns before attempting the switch to a new frame. This causes the method to be deallocated and therefore, the channel. The this causes the frame to be reactivated for killing and this is where the trouble starts.... When hard switching, receive() never returns, and the problem doesn't surface. K
> -----Original Message----- > From: [email protected] [mailto:stackless- > [email protected]] On Behalf Of Kristján Valur Jónsson > Sent: 10. ágúst 2009 09:04 > To: Richard Tew > Cc: Stefan Reich; [email protected] > Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short > script > > 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 _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
