On 2019-03-28, Antoine Pitrou wrote:
> On Wed, 27 Mar 2019 15:59:25 -0700
> "Gregory P. Smith" wrote:
> >
> > That had a C++ stack trace 1000+ levels deep repeating the pattern of
> >
> > ...
> > @ 0x564d59bd21de 32 func_dealloc
> > @ 0x564d59bce0c1 32 cell_deal
On 2019-03-28 01:38, Tim Peters wrote:
The bad news is that the traschcan mechanism is excruciating, a
long-time source of subtle bugs of its own :-(
It just happens that I created a PR to fix some of the trashcan
problems: see https://bugs.python.org/issue35983 and
https://github.com/python/
On Wed, 27 Mar 2019 15:59:25 -0700
"Gregory P. Smith" wrote:
>
> That had a C++ stack trace 1000+ levels deep repeating the pattern of
>
> ...
> @ 0x564d59bd21de 32 func_dealloc
> @ 0x564d59bce0c1 32 cell_dealloc
> @ 0x564d5839db41 48 tupledeall
[Gregory P. Smith ]
> Good point, I hadn't considered that it was regular common ref
> count 0 dealloc chaining.
It pretty much has to be whenever you see a chain of XXX_dealloc
routines in a stack trace. gcmodule.c never even looks at a
tp_dealloc slot directly, let alone directly invoke a deall
Good point, I hadn't considered that it was regular common ref count 0
dealloc chaining. The processes unfortunately didn't have faulthandler
enabled so there wasn't much info from where in the python code it happened
(now fixed). I'll see if anything looks particularly unusual next time I
hear o
[Gregory P. Smith ]
> ...
> A situation came up the other day where I believe this could've helped.
>
> Scenario (admittedly not one most environments run into): A Python process
> with a C++ extension module implementing a threaded server (threads
> spawned by C++) that could call back into CPytho
https://www.python.org/dev/peps/pep-0556/
This PEP is currently Deferred as nobody is actively working on a test
implementation.
A situation came up the other day where I *believe* this could've helped.
Scenario (admittedly not one most environments run into): A Python process
with a C++ extensi
