[Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc (original) (raw)
Neil Schemenauer nas-python at arctrix.com
Thu Mar 28 15:39:28 EDT 2019
- Previous message (by thread): [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc
- Next message (by thread): [Python-Dev] PEP 587: Python Initialization Configuration
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 funcdealloc > @ 0x564d59bce0c1 32 celldealloc > @ 0x564d5839db41 48 tupledealloc > @ 0x564d59bd21de 32 funcdealloc > @ 0x564d59bce0c1 32 celldealloc > @ 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
- Previous message (by thread): [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc
- Next message (by thread): [Python-Dev] PEP 587: Python Initialization Configuration
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]