[Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc
Neil Schemenauer
nas-python at arctrix.com
Thu Mar 28 15:39:28 EDT 2019
On 2019-03-28, Antoine Pitrou wrote:
> On Wed, 27 Mar 2019 15:59:25 -0700
> "Gregory P. Smith" <greg at krypto.org> wrote:
> >
> > That had a C++ stack trace 1000+ levels deep repeating the pattern of
> >
> > ...
> > @ 0x564d59bd21de 32 func_dealloc
> > @ 0x564d59bce0c1 32 cell_dealloc
> > @ 0x564d5839db41 48 tupledealloc
> > @ 0x564d59bd21de 32 func_dealloc
> > @ 0x564d59bce0c1 32 cell_dealloc
> > @ 0x564d5839db41 48 tupledealloc
> > ...
>
> As Tim said, if you still have a core dump somewhere (or can reproduce
> the issue) it would be nice to know why the "trashcan" mechanism didn't
> trigger.
To expand on this, every time tupledealloc gets called,
Py_TRASHCAN_SAFE_BEGIN also gets invoked. It increments
tstate->trash_delete_nesting. As Tim suggests, maybe
PyTrash_UNWIND_LEVEL is too large given the size of the C stack
frames from func_dealloc + cell_dealloc + tupledealloc.
That theory seems hard to believe though, unless the C stack is
quite small. I see PyTrash_UNWIND_LEVEL = 50. Perhaps the stack
could have been mostly used up before the dealloc sequence started.
The other option is that there is some bug in the trashcan
mechanism. It certainly is some very tricky code.
Regards,
Neil
More information about the Python-Dev
mailing list