<div>Hi,</div><div><br></div><div>I am currently hitting <a href="http://bugs.python.org/issue13992">http://bugs.python.org/issue13992</a>.</div><div><br></div><div>I have a scenario that reproduces the bug after 1 to 2 hours (intensive sqlalchemy and threading). I get the same stack trace as described in the bug.</div>
<div><br></div><div>After spending quite a bit of time trying to understand what could go wrong in the C extensions I use, and not finding anything interesting, I decided to try to find the problem with gdb. The stacktrace I have seems to mean that we are trying to double free something in the frame_dealloc method. See </div>
<div><div><br></div><div>(gdb) bt</div><div>#0 0x000000000046479f in _Py_ForgetReference (op=0x4dc7bc0) at Objects/object.c:2222</div><div>#1 0x0000000000464810 in _Py_Dealloc (op=0x4dc7bc0) at Objects/object.c:2242</div>
<div>#2 0x0000000000559a68 in frame_dealloc (f=0x4997ab0) at Objects/frameobject.c:458</div><div>#3 0x000000000046481d in _Py_Dealloc (op=0x4997ab0) at Objects/object.c:2243</div></div><div><br></div><div>and info in the bug report. Since the frame dealloc method is bracketed with Py_TRASHCAN_SAFE_{BEGIN|END} macros, and they deal with memory management, I had a closer look at those.</div>
<div><br></div><div>I compiled cpython without this trashcan management (replaced the macros by two noops) and reran my scenario and it seems it is not segfaulting anymore.</div><div><br></div><div>I then had a closer look at the PyTrash_destroy_chain method (in object.c). Here is what I think it does :</div>
<div><br></div><div>for each PyObject in the _PyTrash_delete_later linked list do :</div><div> set delete_nesting to 1 (it was 0 when the method was called) so that we don't call destroy_chain again.</div><div> call deallocator for the object</div>
<div> set delete_nesting back to 1.</div><div><br></div><div>The thing is that this deallocator (from what I understood) is also bracketed with Py_TRASHCAN macros. It could potentially cause a long deallocation chain, that will be added to the _PyTrash_delete_later linked list (if it's bigger than the PyTrash_UNWIND_LEVEL). If that happens, it seems that the _PyTrash_delete_later list is going to contain twice the same object, which could in turn cause the double free ?</div>
<div><br></div><div>Note that I am really not sure about this. What I am now almost sure about is that my segfault goes away if I bypass the trashcan mechanism.</div><div><br></div><div>I am currently trying to set the unwind level to something like 5 and get a quicker way to reproduce the bug, but I didn't manage to yet. I am definitely available for help if needed.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>Manu</div>