[Stackless] a stackless crash

Kristján Valur Jónsson kristjan at ccpgames.com
Tue Nov 6 14:44:32 CET 2007



> -----Original Message-----
> From: Christian Tismer [mailto:tismer at stackless.com]
> This is not true, see the start of channelobject.c .
> The channel gets temporarily resurrected, and it is
> anyway visible through its members, since it is the
> head of the taskets that it contains.
> Therefore, it is possible to create new references,
> and the beast stays alive.
> Maybe this was a bad hack in order to save a pointer,
> but it is so right now.
Ok, but do we really need to resurrect it?  If it is only accessible throug the prev- and next pointers, then
it should be simple to just unlink the tasklets before killing them.  Then the channel is gone.

Anyway, we are attempting to kill the tasklet at the end of execution.  If what you are saying is correct, then it might aswell insert itself into the channel at this point too.  I don't see that postponing the tasklet kill until the end of execution avoids the problem.

I think the solution is to make it impossible to do that, by making the channel inaccessible to python code.

>
> > Killing the tasklets at the time we are destroying the channel
>  > seems like a much better place to do it and may even make the
>  > late "kill tasklets with cstacks" code unnecessary.
>
> a) better place than what?
>     You cannot really kill a tasklet immediately. Maybe it would
>     be nicer to try to kill it earlier, yes, considerable,
>     but no guarantee.
Better than waiting until program exit.  So, why can't we wake up the tasklet immediately with an
exception?

>
> b) Why should this late code become unnecessary. Maybe I should
>     write up a (bad) design paper?
>     There always can be any number of taskets floating around,
>     which are not blocked, just remove()d. They need to be cleaned
>     up in the end.

Ok, but where are they linked in?  Do they have valid prev and next pointers?  Remember, the crash comes as a
result of the unlinked tasklets having a null prev and next pointer (since they were unlinked from the channel)

Maybe this is all a non-issue if we just fix the issue with unlinked tasklets...

Okay, it turns out we don't need the channel to see this bug!!!!!
See the two attached files for an even simpler way.  A tasklet with a cstack that does a remove!
No messy channel to muddy the waters.

K




>
> I was about to say "yeah, all right", but then I looked back into
> the sins of another like, and corrected it into
> "sorry, you loose, almost everywhere" :-)
>
> cheers - chris
>
> --
> Christian Tismer             :^)   <mailto:tismer at stackless.com>
> tismerysoft GmbH             :     Have a break! Take a ride on
> Python's
> Johannes-Niemeyer-Weg 9A     :    *Starship*
> http://starship.python.net/
> 14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
> work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
> PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>        whom do you want to sponsor today?   http://www.stackless.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.py
Type: application/octet-stream
Size: 250 bytes
Desc: crash.py
URL: <http://www.stackless.com/pipermail/stackless/attachments/20071106/a0460f5b/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _crash.cpp
URL: <http://www.stackless.com/pipermail/stackless/attachments/20071106/a0460f5b/attachment.txt>


More information about the Stackless mailing list