The following simple code works perfectly on W2K, WXP, Ubuntu, OSX10.4 
OSX10.5. It, however, stopped working on OSX10.6 (Snow Leopard): It 
simply crashes. It is a strptime() which causes problems to me.

Any idea? Any workaround?

import time
import thread

def test():
    print "TS: "
    print "%s" % str(time.strptime("2009-09-09 16-56-37", "%Y-%m-%d %H-
%M-%S"))
    
thread.start_new_thread (test, ())
time.sleep(2.0)

It fails for me as well on 10.6 (Intel) with 2.6 and trunk and did not 
fail on 10.5 (ppc). time.strptime does an import of a python module from C 
code so, not surprisingly, adding a time.strptime call in the main module 
prior to the thread.start_new_thread avoids the crash.

Attached is the stack trace of the crash with 2.6.4rc1.

The suggested workaround helped to solve the issue to me. Thank for it 
very much.

I am using Python 2.4.4 and cannot upgrade to anything above 2.4 due to 
incompatibility between .pyc files (I have tenths of production sites with 
Python 2.4.4, with automatic update feature, onto which I only populate 
the .pyc files only, so upgrading to Python 2.5.x+ would cause all my 
sites to crash upon the next automatic update).

Consequently, from my perspective, this issue is solved and may be closed.

It's confirmed on 2.5 - trunk, but it is not an issue in at least 3.1 and 
py3k.

As Ned pointed out, time imports _strptime.py from the standard library 
which is known to be a no-no. But still, it's odd that it crashed on Snow 
Leopard but not Leopard. I will leave this issue open for Ronald to make a 
call as to whether this is a Python issue or not as Python is dying in 
__CFInitialize().

The crash happens whenever you import code on a secondairy thread.

I consider this a platform bug in the implementation of dlopen, because 
the crash also occurs with this variant on test():

def test():
    print "DL"
    p = os.path.join(os.path.dirname(time.__file__), '_locale.so')
    m = dl.open(p)
    print m

(Don't forget to import dl and os before running the code).

I'm investigating a workaround.

FWIW, I've filed an issue with Apple for this: Radar #7330231

The crash is caused by loading any extension that happens to link with 
CoreFoundation on a secondary thread, unless CoreFoundation was already 
initialized.

The CF framework contains a constructor that explicitly aborts when it 
is not called on the main thread (all of this on Snow Leopard only).

I've found a workaround for this issue: ensure that Python is linked to 
the CoreFoundation framework, that way CF will be initialized when 
Python starts.

I'm working on a clean patch for this.

I committed a fix in r76403 (trunk), r76404 (2.6), r76405 (3.2), 76406 
(3.1)