Finalization problems

[Robin Becker]

In article <mailman.998680317.19173.python-list at python.org>, Tim Peters
<tim.one at home.com> writes
>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).
yes he's using -v and no I don't think he's use to gdb. He couldn't see
the core file.
>
>If this app is threaded, I'd suspect that before I'd suspect refcounts.

No threads. Apparently the app has done everything expected and bombs on
exit. We had some similar things on NT when using the wrong socket
library (ie not wsock32.dll). I believe this app worked ok with
Solaris+2.0, but am not absolutely certain.

I will attempt a freeBSD port and see if I can provoke something there.

>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.
>
>

-- 
Robin Becker