[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc
From:       Neil Schemenauer <nas-python () arctrix ! com>
Date:       2019-03-28 19:39:28
Message-ID: 20190328193928.pg2g3skia5ggpkjx () python ! ca
[Download RAW message or body]

On 2019-03-28, Antoine Pitrou wrote:
> On Wed, 27 Mar 2019 15:59:25 -0700
> "Gregory P. Smith" <greg@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-marcsub-zyf4%40marc.info
[prev in list] [next in list] [prev in thread] [next in thread]