Finalization problems

[Tim Peters]

[Robin Becker]
> A colleague reports finalization problems with a particular extension
> running under 2.1.1 and Solaris. The problems don't occur with NT. he
> reports sigabort right after the cleanup __builtins__ and before the
> cleanup ints. Both Python-2.1.1 and the extension are built using gnu
> tools.
>
> The distinguishing feature is that the extension is used more than once
> in the cases when the abort occurs.
>
> Not having access to the corporate Solaris machine I can only ask what
> sort of things might cause this eg do I have to search for all known
> python variables looking to see if they are correctly ref counted etc?
>
> Are there any things I can try with the NT version?

Not enough info.  Does your colleague know how to use gdb?  If not, you're
in for a lot of blind guessing.  The top-level place to look is
Py_Finalize() in Python/pythonrun.c.  Cleaning builtins occurs near the end
of the call to PyImport_Cleanup(), and about a dozen other things happen
between then and the time ints are cleaned up (I assume you're deriving
sense of time from -v output, which doesn't normally *print* anything
between the builtin and int cleanups).

If this app is threaded, I'd suspect that before I'd suspect refcounts.
Solaris is more reluctant than NT to switch threads, so race bugs are more
likely to show up under one than the other.  We've had legit race bugs in
Python that were easy to provoke under Linux but seemingly impossible under
Windows, and vice versa.  For example, if the extension is mucking with
threads, and doing so incorrectly near shutdown time (like calling a Python
C API function when Py_IsInitialized() returns false), it's much more likely
to blow up under an OS reluctant to switch threads.