This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Mark.Shannon, christian.heimes, jdemeyer, lukasz.langa, methane, miss-islington, nascheme, pablogsal, petr.viktorin, pitrou, tim.peters, vstinner
Date 2019-09-27.21:14:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1569618881.38.0.988221818863.issue38006@roundup.psfhosted.org>
In-reply-to
Content
> Is the behavior of tp_clear the key to this bug?

Once func_clear(my_func) is called, calling my_func() will crash: my_func() is unsuable.

Because of a complex dance involving borrowed references, the function is called *after* it's cleared.

Pablo's PR 15645 works around the problem by detecting this very specific case: call a function "after it's cleared" (while it's being garbage collected in practice).

Honestly, I'm still not sure how *exactly* the bug is triggered. I tried but failed to reproduce the initial cffi crash. reproducer.tar.gz is still a giant piece of code. I failed to simplify it to a few objects.

According to Pablo, gc_crash.py is a *different* (but similar) bug.

I would only be confident in approving a fix once I would be confident that I understood *exactly* how the initial bug (reproducer.tar.gz) occurred.
History
Date User Action Args
2019-09-27 21:14:41vstinnersetrecipients: + vstinner, tim.peters, nascheme, pitrou, christian.heimes, petr.viktorin, methane, lukasz.langa, Mark.Shannon, jdemeyer, pablogsal, miss-islington
2019-09-27 21:14:41vstinnersetmessageid: <1569618881.38.0.988221818863.issue38006@roundup.psfhosted.org>
2019-09-27 21:14:41vstinnerlinkissue38006 messages
2019-09-27 21:14:41vstinnercreate