Author vstinner
Recipients vstinner
Date 2019-10-07.10:48:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
A bug in Python/hamt.c was only discovered 4 months after the code was added to Python:

The problem was that an object was tracked by the GC, whereas calling its traverse method crashed Python... depending when the traverse method is called exactly.


  PyObject_GC_Track(<partially initialized object>);
  obj2 = PyObject_GC_NewVar(...);
  <finish to initialize the first object>

The problem is that PyObject_GC_NewVar() can trigger a GC collection which uses the partially initialized object, and then we get a cryptic crash in the GC (usually seen in visit_decref()).

I propose to make PyObject_GC_Track() stricter: validate that the object seems to be "valid" or "fully initialized". From the GC point of view, it means that calling tp_traverse must not crash.

Attached PR is a concrete implementation.

This issue is a follow-up of my previously failed attempt bpo-36389 "Add gc.enable_object_debugger(): detect corrupted Python objects in the GC". While bpo-36389 attempts to discoverd corrupted objects once a GC collection is triggered, this issue is restricted to objects entering the GC.

First problem: my PR breaks Modules/pyexpat.c whereas the code is not strictly a bug: in Python 3.8, it's ok to put a partially initialized object into the GC if no GC collection can be triggered before the object is fully initialized. In Modules/pyexpat.c case, the code looks safe from that point of view.

It means that such change is a backward incompatible change. IMHO it's a good step forward, since it is likely to discovered hidden bugs.
Date User Action Args
2019-10-07 10:48:58vstinnersetrecipients: + vstinner
2019-10-07 10:48:58vstinnersetmessageid: <>
2019-10-07 10:48:58vstinnerlinkissue38392 messages
2019-10-07 10:48:58vstinnercreate