[Stackless] profile error, again
Kristján Valur Jónsson
kristjan at ccpgames.com
Thu Jan 31 11:45:52 CET 2008
With the latest and simplest repro, I have traced this hither and thither.
I can see what happens, but I don't have enough knowledge of the ways of stackless to tell where it goes off track.
I did send some details to Christian... Basically, we have packed the return value from the tasklet (None) into Py_UnwindToken, and returned out of the frame scheduler. The tasklet is then killed by bombing it. (why do we need to 'kill' a tasklet that has run its course?) It is woken up using a hard swithch (again, is this normal?) and finds itself in a frame scheduler where the next frame is this "shadow frame", restore_tracing(), which assumes that there is no value packed in Py_UnwindToken. And then it asserts in debug builds and goes on to be weird in non-debug builds.
Disabling the hooking in of the "restore_tracing()" callback (scheduling, line 858) will fix it. I wonder if this is something that should go away? After all, there is the other function, transfer_with_exc(), which is supposed to switch the tracing stuff back and forth.
At any rate, I have a patch which restores the level of saninty we require, by adding a thread local flag, globaltrace into the stackless module. See the attached patch for details. When set, there is no juggling of the tracing stuff in the TLS during tasklet switching, and we can thus globally enable and disable profiling for the entire thread. Do you think this is sane enough to go in?
But I agree with you that we ought to fix the crash regardless, but I think I need some help with it :(
> -----Original Message-----
> From: Richard Tew [mailto:richard.m.tew at gmail.com]
> Sent: Wednesday, January 30, 2008 18:34
> To: Kristján Valur Jónsson
> Cc: Stackless mailing list
> Subject: Re: [Stackless] profile error, again
> On Jan 28, 2008 5:27 AM, Kristján Valur Jónsson <kristjan at ccpgames.com>
> > Okay, I've managed to simplify this a bit.
> What are the repercussions of removing the Stackless specific
> behaviour? That is, is it still possible to debug, profile and trace
> with your own custom tasklet debugger, or is the Stackless specific
> behaviour there for a reason?
> Regardless of whether there is a change in behaviour or a flag to
> alternate, I think that the problem you are experiencing should be
> debugged anyway. Is there any reason you haven't debugged it for us
> and either provided an explanation or a patch? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4112 bytes
More information about the Stackless