[Stackless] a stackless crash

Kristján Valur Jónsson kristjan at ccpgames.com
Sun Oct 28 22:06:03 CET 2007


Ok, I managed to analyze this a bit better during my flight from Boston to SF.

What is happening is this:

1)      A tasklet with a C stack is sleeping in blue.pyos.Yield.  It does a receive on a channel.  It does not increment any references to that channel.

2)      We start shutting down and as part of that, we release the channel.  It gets destroyed, in the process it unlinks the sleeping tasklet which is now unlinked (with next and prev pointers being NULL(

3)      We enter PyStackless_kill_tasks_with_stacks.  It finds the tasklet and tries to unlink it in order to relink it.  But it is nowhere linked so the unlink crashes.

Now, I tried fixing it by checking for NULL in step 3 and skipping the unlink.  But I then got a crash, because a subsequent PyTasklet_Kill() call effectively steals the reference to the tasklet (it does a decref after killing it) and this causes a crash during GC.
Increfing the tasklet before calling KILL fixes that.

Now, here are some questions, mostly for our chief Guru:


1)      Is this scenario supposed to be possible?  I tried reproing it with pure python but I found no way to let a tasklet sleep on a channel without increfing the channel.  See the attached .py file.  On the other hand, the code that deletes a channel does unlink any sleeping tasklets, so it would appear that the design is intended to cope with that.  At any rate, we probably don't want a sleeping tasklet to hold a reference to a channel since then we have a reference cycle.

2)      Assuming it is possible, and the only way to trigger it is within the context of eve, are my bugfixes correct?  I.e. checking for NULL and not unlinking, and increfing before the PyTasklet_Kill?

Also, any help in reproing the case in pure python would be appreciated.
N.b. I get the expected behavior (no incref in sleep) if I run in softswitching mode.  Only then the bug isn't encountered because only tasklets with cstacks matter here.

Again, please see the attached file for info.

K

From: stackless-bounces at stackless.com [mailto:stackless-bounces at stackless.com] On Behalf Of Kristján Valur Jónsson
Sent: Friday, October 26, 2007 14:16
To: Stackless mailing list
Subject: [Stackless] a stackless crash

Hello there.
I have a crash case during early exit of stackless.  The call stack is:

>             python25_d.dll!slp_kill_tasks_with_stacks(_ts * ts=0x00000000)  Line 344 + 0x31 bytes  C
                python25_d.dll!PyStackless_kill_tasks_with_stacks(int allthreads=1)  Line 369 + 0x12 bytes         C
                python25_d.dll!Py_Finalize()  Line 379 + 0x7 bytes           C
                blueD.dll!BluePyOS::Shutdown(int level=2)  Line 899 + 0x8 bytes              C++
                blueD.dll!BlueOS::Shutdown()  Line 554 + 0x17 bytes      C++
                ExeFileD.exe!ExeFile::Run()  Line 286 + 0x19 bytes           C++
                ExeFileD.exe!WinMain_Guarded(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, char * cmdline=0x00152325, HINSTANCE__ * __formal=0x00000000)  Line 218    C++
                ExeFileD.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hi2=0x00000000, char * cmdline=0x00152325, int arg=10)  Line 146 + 0x15 bytes C++
                ExeFileD.exe!__tmainCRTStartup()  Line 589 + 0x35 bytes            C
                ExeFileD.exe!WinMainCRTStartup()  Line 414     C
                kernel32.dll!_BaseProcessStart at 4()  + 0x23 bytes

And I am in the SLP_CHAIN_REMOVE macro.
the l and r variables are both null.  That is why it crashes, it is trying to unlink a tasklet that has prev and next both equal to NULL.

Now, why does this happen?  What is this code trying to do and is this a valid state for the tasklet object?

Cheers,
Kristján
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20071028/dbe145c2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash2.py
Type: application/octet-stream
Size: 884 bytes
Desc: crash2.py
URL: <http://www.stackless.com/pipermail/stackless/attachments/20071028/dbe145c2/attachment.obj>


More information about the Stackless mailing list