The following script raises several "_strptime_time" AttributeErrors (on OS X 10.4 at least).

If time.strptime is used before starting the threads, then no exception is raised (the issue may thus come from strptime.py not being imported in a thread safe manner).


import time
import thread

def f():
    for m in xrange(1, 13):
        for d in xrange(1,29):
            time.strptime("2010%02d%02d"%(m,d),"%Y%m%d")

for _ in xrange(10):
    thread.start_new_thread(f, ())
time.sleep(3)


> Traceback (most recent call last):
>   File "[...]/test.py", line 75, in f
>     time.strptime("2010%02d%02d"%(m,d),"%Y%m%d")
> AttributeError: _strptime_time

With 10.6's stock python, I've had this test either work or crash Python.

On trunk, I get it to either work or give the same error as the original report.

Unfortunately I've been unable to get it to crash again in a debugger so I can get a stack trace. But I'm still trying.

Which version is "10.6's stock python"? Note that r59678 fixed a "problem with dead locks when mixin threads and imports".

Oops, sorry for not specifying that. It's:
Python 2.6.4 (r264:75706, Jan 27 2010, 12:09:19) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin

Lib/_strptime.py itself should be thread-safe. I am guessing that it has something to do with the way the C code in time.c imports _strptime.py. A possible solution if it is the C code's import stuff is to create a time.py that imports a _time.c, but that's a total guess as to whether that will solve anything.

It would be easier to move the PyImport_ImportModuleNoBlock("_strptime") currently in strptime() into the timemodule.c init function.

FYI there's been a proposal to create a time.py module anyway in order to add some pure python functions not worth writing in c.

For reference, it's issue 7989.

I just tried it again under gdb on MacOS 10.6, the supplied python 2.6.4 and got this backtrace:

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to process 61133]
0x00007fff87a4b790 in __CFInitialize ()
(gdb) bt
#0  0x00007fff87a4b790 in __CFInitialize ()
#1  0x00007fff5fc0d5ce in __dyld__ZN16ImageLoaderMachO11doImageInitERKN11ImageLoader11LinkContextE ()
#2  0x00007fff5fc0d607 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#3  0x00007fff5fc0bcec in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#4  0x00007fff5fc0bc9d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#5  0x00007fff5fc0bc9d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#6  0x00007fff5fc0bda6 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#7  0x00007fff5fc08fbb in __dyld_dlopen ()
#8  0x00007fff8276fe00 in dlopen ()
#9  0x00000001000e876f in _PyImport_GetDynLoadFunc ()
#10 0x00000001000d2ce4 in _PyImport_LoadDynamicModule ()
#11 0x00000001000d0fbf in import_submodule ()
#12 0x00000001000d14da in load_next ()
#13 0x00000001000d17ec in PyImport_ImportModuleLevel ()
#14 0x00000001000aeeb3 in builtin___import__ ()
#15 0x000000010000c092 in PyObject_Call ()
#16 0x00000001000b00e7 in PyEval_CallObjectWithKeywords ()
#17 0x00000001000b43ae in PyEval_EvalFrameEx ()
#18 0x00000001000b8fd0 in PyEval_EvalCodeEx ()
#19 0x00000001000b90b6 in PyEval_EvalCode ()
#20 0x00000001000cdeb0 in PyImport_ExecCodeModuleEx ()
#21 0x00000001000cf112 in load_source_module ()
#22 0x00000001000d0fbf in import_submodule ()
#23 0x00000001000d14da in load_next ()
#24 0x00000001000d17ec in PyImport_ImportModuleLevel ()
#25 0x00000001000aeeb3 in builtin___import__ ()
#26 0x000000010000c092 in PyObject_Call ()
#27 0x00000001000b00e7 in PyEval_CallObjectWithKeywords ()
#28 0x00000001000b43ae in PyEval_EvalFrameEx ()
#29 0x00000001000b8fd0 in PyEval_EvalCodeEx ()
#30 0x00000001000b90b6 in PyEval_EvalCode ()
#31 0x00000001000cdeb0 in PyImport_ExecCodeModuleEx ()
#32 0x00000001000cf112 in load_source_module ()
#33 0x00000001000d0fbf in import_submodule ()
#34 0x00000001000d14da in load_next ()
#35 0x00000001000d17ec in PyImport_ImportModuleLevel ()
#36 0x00000001000aeeb3 in builtin___import__ ()
#37 0x000000010000c092 in PyObject_Call ()
#38 0x000000010000fbe5 in PyObject_CallFunction ()
#39 0x00000001000d1f9b in PyImport_Import ()
#40 0x00000001000d250f in PyImport_ImportModuleNoBlock ()
#41 0x0000000100515733 in time_strptime ()
#42 0x00000001000b8278 in PyEval_EvalFrameEx ()
#43 0x00000001000b8fd0 in PyEval_EvalCodeEx ()
#44 0x000000010003b355 in function_call ()
#45 0x000000010000c092 in PyObject_Call ()
#46 0x00000001000b00e7 in PyEval_CallObjectWithKeywords ()
#47 0x00000001000ef7ae in t_bootstrap ()
#48 0x00007fff827a2f8e in _pthread_start ()
#49 0x00007fff827a2e41 in thread_start ()
(gdb)

Attribute error confirmed on linux on trunk and py3k.

Attribute error confirmed on OSX, and py3k.

http://codereview.appspot.com/2371041

MunSic,

It looks like issue7980.patch is just a unit test.  Do you have a patch to fix the issue?

RDM> FYI there's been a proposal to create a time.py module anyway
RDM> in order to add some pure python functions not worth writing in c.
RDM> For reference, it's issue 7989.

Issue #7989 was retargeted to deal with datetime module.  The time.py issue is #9528.

> Do you have a patch to fix the issue?
no, I don't. I just wanted to move stage from "unittest needed" to "needs patch" :)

After reading issue8098, now I realized that this is broad issue as belopolsky said in msg110095. 


For new reader of this issue after me, I would like to share my understanding.

Patch like below can solve this ticket. (changing "ImportModuleNoBlock" call to "ImportNoBlock")

 static PyObject *
 time_strptime(PyObject *self, PyObject *args)
 {
-    PyObject *strptime_module = PyImport_ImportModuleNoBlock("_strptime");
+    PyObject *strptime_module = PyImport_ImportModule("_strptime");


But "the function PyImport_ImportModuleNoBlock() was introduced and used in modules such as the time module to supposedly avoid deadlocks when using threads." 

So we could not apply that patch.

It seems to me that this is related to if not a duplicate of issue 8098.

As per my comments on Issue11108 - I suspect that PyImport_ImportModuleNoBlock is a bit of a red herring here - in Python 2.5 and earlier versions (well before PyImport_ImportModuleNoBlock was added), we have occasionally seen 'AttributeError: strptime' from threaded code calling time.strptime(), so whatever this bug is, I don't believe it's caused by the call now being non-blocking from 2.6 onwards.

I recognize the same problem problem at linux with 4 core 64 processor. The python version is 2.6.5 . Looks like occured randomly but maybe this is depend from thread sequence.

For the record, issue9260 proposes to fix the issues with PyImport_ImportModuleNoBlock.

I'm still seeing this, in the 2.7.2 that comes with OS X 10.8.2.