Hi,<br><br>This is to report a possible bug in Stackless 2.6. I get a segfault when running the following script:<br><br>import stackless<br>def F():<br>  print 'f-schedule-remove-reached'<br>  stackless.schedule_remove(None)<br>
stackless.tasklet(F)()<br>stackless.schedule_remove(None)<br><br>Valgrind reveals the following stack trace:<br><span id=":z3" class="es el"><br>==19749== Memcheck, a memory error detector<br>==19749== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.<br>
==19749== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info<br>==19749== Command: ./w.py<br>==19749== Parent PID: 19748<br>==19749== <br>==19749== Invalid write of size 8<br>==19749==    at 0x49574C: PyEval_EvalFrame_value /usr/local/google/python-2.65/Python/ceval.c:957<br>
==19749==    by 0x49BA5F: slp_frame_dispatch_top /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:719<br>==19749==    by 0x49E925: slp_run_tasklet /usr/local/google/python-2.65/Stackless/module/scheduling.c:1204<br>
==19749==    by 0x49C957: slp_eval_frame /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:299<br>==19749==    by 0x49C9C5: climb_stack_and_eval_frame /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:266<br>
==19749==    by 0x49C8D3: slp_eval_frame /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:294<br>==19749==    by 0x494581: PyEval_EvalCode /usr/local/google/python-2.65/Python/ceval.c:543<br>==19749==    by 0x4C8998: PyRun_FileExFlags /usr/local/google/python-2.65/Python/pythonrun.c:1379<br>
==19749==    by 0x4C8C66: PyRun_SimpleFileExFlags /usr/local/google/python-2.65/Python/pythonrun.c:952<br>==19749==    by 0x418123: Py_Main /usr/local/google/python-2.65/Modules/main.c:572<br>==19749==    by 0x56EC1C3: (below main) in /lib/<a href="http://libc-2.7.so">libc-2.7.so</a><br>
==19749==  Address 0x0 is not stack'd, malloc'd or (recently) free'd<br>==19749== <br>==19749== <br>==19749== Process terminating with default action of signal 11 (SIGSEGV)<br>==19749==  Access not within mapped region at address 0x0<br>
==19749==    at 0x49574C: PyEval_EvalFrame_value /usr/local/google/python-2.65/Python/ceval.c:957<br>==19749==    by 0x49BA5F: slp_frame_dispatch_top /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:719<br>==19749==    by 0x49E925: slp_run_tasklet /usr/local/google/python-2.65/Stackless/module/scheduling.c:1204<br>
==19749==    by 0x49C957: slp_eval_frame /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:299<br>==19749==    by 0x49C9C5: climb_stack_and_eval_frame /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:266<br>
==19749==    by 0x49C8D3: slp_eval_frame /usr/local/google/python-2.65/Stackless/core/stacklesseval.c:294<br>==19749==    by 0x494581: PyEval_EvalCode /usr/local/google/python-2.65/Python/ceval.c:543<br>==19749==    by 0x4C8998: PyRun_FileExFlags /usr/local/google/python-2.65/Python/pythonrun.c:1379<br>
==19749==    by 0x4C8C66: PyRun_SimpleFileExFlags /usr/local/google/python-2.65/Python/pythonrun.c:952<br>==19749==    by 0x418123: Py_Main /usr/local/google/python-2.65/Modules/main.c:572<br>==19749==    by 0x56EC1C3: (below main) in /lib/<a href="http://libc-2.7.so">libc-2.7.so</a><br>
==19749==  If you believe this happened as a result of a stack<br>==19749==  overflow in your program's main thread (unlikely but<br>==19749==  possible), you can try to increase the size of the<br>==19749==  main thread stack using the --main-stacksize= flag.<br>
==19749==  The main thread stack size used in this run was 8388608.<br>==19749== <br>==19749== HEAP SUMMARY:<br>==19749==     in use at exit: 1,899,272 bytes in 12,359 blocks<br>==19749==   total heap usage: 33,505 allocs, 21,146 frees, 4,788,307 bytes allocated<br>
==19749== <br>==19749== LEAK SUMMARY:<br>==19749==    definitely lost: 0 bytes in 0 blocks<br>==19749==    indirectly lost: 0 bytes in 0 blocks<br>==19749==      possibly lost: 1,780,658 bytes in 11,518 blocks<br>==19749==    still reachable: 118,614 bytes in 841 blocks<br>
==19749==         suppressed: 0 bytes in 0 blocks<br>==19749== Rerun with --leak-check=full to see details of leaked memory<br>==19749== <br>==19749== For counts of detected and suppressed errors, rerun with: -v<br>==19749== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 0)<br>
<br>It fails in PUSH(retval). The relevant C source lines are (from line 955 of ceval.c):<br><br>        if (f->f_execute == PyEval_EvalFrame_value) {<br>        /* this is a return */<br>                PUSH(retval); /* we are back from a function call */<br>
        }<br><br>I'm using the following version of Stackless Python 2.6:<br><br>  svn checkout <a href="http://svn.python.org/projects/stackless/tags/python-2.65/">http://svn.python.org/projects/stackless/tags/python-2.65/</a><br>
  At revision 81084.<br>  Python 2.6.5 Stackless 3.1b3 060516 (python-2.65:81084M, May 11 2010, 16:52:04) <br>  [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2<br><br>I could reproduce the segfault on both a 32-bit and a 64-bit system:<br>
<br>  Linux host1 2.6.31-20-generic-pae #57-Ubuntu SMP Mon Feb 8 10:23:59 UTC 2010 i686 GNU/Linux<br>  Linux host2 2.6.24-... #1 SMP Tue Mar 30 18:11:30 UTC 2010 x86_64 GNU/Linux<br><br>Is there a fix available?<br><br>Thanks,<br>
<br>Péter<br></span>