[Stackless] A new crash bug
Kristján Valur Jónsson
kristjan at ccpgames.com
Sat Oct 20 18:35:18 CEST 2007
1) Yes, the failure actually happened when gc_clear() is called on the channel. There are some four objects in the 'unreacable' list at this time (including the frame belonging to the tasklet) but it is the channel that is called first, and during the awakening of the tasklet object that the longjump-like behaviour appears. As I said, I really have to singlestep further, since the "step over" feature of the debugger is broken by the stackless stack switching. Whenever I step over stuff, I find myself in the crash case...
I'll report more later.
> -----Original Message-----
> From: Richard Tew [mailto:richard.m.tew at gmail.com]
> Sent: 20. október 2007 10:58
> To: Kristján Valur Jónsson
> Cc: Stackless mailing list
> Subject: Re: [Stackless] A new crash bug
> On 10/20/07, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:
> > 1) Why do we need to awaken tasklets when channels are collected?
> Are you sure that the tasklet isn't being garbage collected itself, as
> the last reference to it inside the channel is removed? Then the
> tasklet would be killed, by having a TaskletExit raised on it. I have
> debugged crash bugs with this behaviour in the past.
> > 2) Why does awakening the tasklet cause this longjump out of the
> > 3) Why do we find the frame in the exception state then? (I must
> investigate.) Was it there when gc.collect() was entered, or did it enter
> it as part of awakening the tasklet? If the former, then there must be a
> reference bug since in that case it shouldn't have entered the
> 'unreachable' list in the first place.
> I am presuming these follow from the answer to 1).
More information about the Stackless