Not all types have "trashcan" protection and tp_dealloc can overflow stack

[nascheme]

We occasionally fix these kinds of bugs, like GH-102356. However, the fix by adding the "trashcan" macros to the tp_dealloc method only fixes that specific type. It would be better to have a more generic fix. A crash due to the C stack overflow leaves the user mystified as to what the problem is and these kinds of bugs could be hard to reproduce (requiring long chains of objects calling tp_dealloc recursively).

Linked PRs

• GH-124715: trashcan protection for all GC objects #124716
• GH-124715: Move trashcan mechanism into Py_Dealloc #132280
• gh-124715: Fix method_dealloc(): use PyObject_GC_UnTrack() #133199
• Revert "gh-124715: Fix method_dealloc(): use PyObject_GC_UnTrack() (#133199)" #133434

[nascheme]

Regarding untracking, when I was working on my "integrate trashcan PR", I started wondering if _PyObject_GC_UNTRACK() should just be changed to check if the object is already untracked and not crash. I originally made it not safe to call twice because I wanted the tiny performance benefit (avoid the branch, I wanted GC support to have as little extra overhead as possible). However, in retrospect, I think it was a mistake. Knowing when it is safe to call _PyObject_GC_UNTRACK() in theory is possible but in practice it gets really painful. If you look at typeobject.c, it has to take great care to avoid _PyObject_GC_UNTRACK() from crashing.

Maybe we should profile this and see if it has any performance impact at all? There has been many bugs related to this over the years.