Py_Finalize(): disabled the second call of cyclic gc, and added extensive

comments about why both calls to cyclic gc here can cause problems.

Already fixed on the trunk.  Since the calls were introduced in 2.3,
that's the end of it.

diff --git a/Misc/NEWS b/Misc/NEWS
index e0d5c8453a13389f3426eee61fb173297fb18263..7731c7ad59662caf322b94b9d430099ab0a2659a 100644 (file)
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -33,6 +33,16 @@ Core and builtins
   in a debug build, a segfault occurred reliably very soon after).
   This has been repaired.
 
+- At Python shutdown time (Py_Finalize()), 2.3 called cyclic garbage
+  collection twice, both before and after tearing down modules.  The
+  call after tearing down modules has been disabled, because too much
+  of Python has been torn down then for __del__ methods and weakref
+  callbacks to execute sanely.  The most common symptom was a sequence
+  of uninformative messages on stderr when Python shut down, produced
+  by threads trying to raise exceptions, but unable to report the nature
+  of their problems because too much of the sys module had already been
+  destroyed.
+
 - Patch #820195: object.__contains__() now returns True or False instead
   of 1 or 0.
 

diff --git a/Python/pythonrun.c b/Python/pythonrun.c
index d32c376209f37590e31dc80aa6cb8ad63f64c6f1..715c4649c6085945d676f3762f7b6f603d5ec18a 100644 (file)
--- a/Python/pythonrun.c
+++ b/Python/pythonrun.c
@@ -332,15 +332,40 @@ Py_Finalize(void)
        warnings_module = NULL;
 
        /* Collect garbage.  This may call finalizers; it's nice to call these
-          before all modules are destroyed. */
+        * before all modules are destroyed.
+        * XXX If a __del__ or weakref callback is triggered here, and tries to
+        * XXX import a module, bad things can happen, because Python no
+        * XXX longer believes it's initialized.
+        * XXX     Fatal Python error: Interpreter not initialized (version mismatch?)
+        * XXX is easy to provoke that way.  I've also seen, e.g.,
+        * XXX     Exception exceptions.ImportError: 'No module named sha'
+        * XXX         in <function callback at 0x008F5718> ignored
+        * XXX but I'm unclear on exactly how that one happens.  In any case,
+        * XXX I haven't seen a real-life report of either of these.
+         */
        PyGC_Collect();
 
        /* Destroy all modules */
        PyImport_Cleanup();
 
        /* Collect final garbage.  This disposes of cycles created by
-          new-style class definitions, for example. */
+        * new-style class definitions, for example.
+        * XXX This is disabled because it caused too many problems.  If
+        * XXX a __del__ or weakref callback triggers here, Python code has
+        * XXX a hard time running, because even the sys module has been
+        * XXX cleared out (sys.stdout is gone, sys.excepthook is gone, etc).
+        * XXX One symptom is a sequence of information-free messages
+        * XXX coming from threads (if a __del__ or callback is invoked,
+        * XXX other threads can execute too, and any exception they encounter
+        * XXX triggers a comedy of errors as subsystem after subsystem
+        * XXX fails to find what it *expects* to find in sys to help report
+        * XXX the exception and consequent unexpected failures).  I've also
+        * XXX seen segfaults then, after adding print statements to the
+        * XXX Python code getting called.
+        */
+#if 0
        PyGC_Collect();
+#endif
 
        /* Destroy the database used by _PyImport_{Fixup,Find}Extension */
        _PyImport_Fini();