On Dec 7, 2010, at 10:08 PM, Richard Tew wrote:

> On Mon, Dec 6, 2010 at 6:55 AM, Daniel Norberg <[email protected]> 
> wrote:
>> I've discovered a possible bug in Stackless 2.6 on Mac OS X Snow Leopard.
>> 
>> Running the following script using a x86_64 stackless on Mac OS X Snow 
>> Leopard produces a bus error.
>> 
>>    import stackless
>>    stackless.tasklet(lambda:None)().remove()
>> 
>> Compiling stackless using CC="gcc -arch i386" makes the problem go away so 
>> it seems to be x86_64 specific.
> 
> Hi Daniel,
> 
> This just involves us trying to reproduce and debug it on a non-MacOS
> computer (none of us have one), or getting shell access to one to do
> so if we cannot.
> 
> A solid reproduction case and a clear description of what code you are
> seeing the problem in, is more than sufficient.  I expect the call
> stack would be partly gibberish and not that helpful anyway.
> 
> Cheers,
> Richard.


Richard - I suspect you meant you don't have a MacOS machine...

I do, and I verified this does occur in 2.6.5 and (since I happened to have a 
version built with some debugging)
quickly concluded that it happens during Py_Finalize (in particular when the 
dance
to do tasklet stack cleanup happens with the "main" tasklet).  Someone's stack 
is corrupt after
an slp_restore_cstack.

However, this does NOT occur in the branch of Stackless 2.7 that I have around,
so my interest in pursuing this is pretty low... (if someone has an idea where
to look specifically I could devote a bit of time to it -- but not much...)

-------snip--------

Python 2.6.5 Stackless 3.1b3 060516 (release26-maint:87131M, Dec  8 2010, 
08:37:00) 

> climb_stack_and_transfer (cstprev=<value temporarily unavailable, due to 
> optimizations>, 
> cst=<value temporarily unavailable, due to optimizations>, prev=<value 
> temporarily 
> unavailable, due to optimizations>) at ./Stackless/core/slp_transfer.c:104
> 104   }
> (gdb) n
> 0x000000010011499e in dyld_stub___stack_chk_fail ()
> (gdb) s
> Single stepping until exit from function dyld_stub___stack_chk_fail, 
> which has no line number information.
> 
> Program received signal SIGABRT, Aborted.
> 0x00007fff868b0616 in __kill ()




_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless

Reply via email to