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.

I am still seeing this in 2.7.5, has a patch been created yet?

There's no patch posted here, and the issue is still open, so no.

On the other hand, the way imports are handled in 3.3 and later is a bit different, and if I run the unit test (which does still fail for me on 2.7 tip) on 3.3 and 3.4 tip it passes.

Given that, I'm guessing it is likely that none of the current Python committers are going to have time to look in to this, so unless someone else comes up with a patch, it isn't likely to get fixed in 2.7.

This bug has not been fixed in 2.7.6 on OSX 10.9.2.

This is a patch attempt to fix issue: import the _strptime module at time / datetime module load instead of method call.

Please note that the test is not fully reliable: it may pass without the patch / on current version, since threaded execution isn't controlled

There are probably reasons why the import is currently done lazily, so I would advise against changing this in 2.7, unless the reasons are investigated and clearly understood.

This issue should be noted in the documentation of strptime in the time and datetime modules and/or the thread module.  As it stands there is no good way for a user of these modules to learn of this problem until one day the right race conditions exist to expose the problem.


Perhaps the following notes will do?

https://docs.python.org/2/library/time.html#time.strptime

Thread safety: The use of strptime is thread safe, but with one important caveat.  The first use of strptime is not thread safe because the first use will import _strptime.  That import is not thread safe and may throw AttributeError or ImportError.  To avoid this issue, import _strptime explicitly before starting threads, or call strptime once before starting threads.

https://docs.python.org/2/library/datetime.html
(under strptime())

See time.strptime() for important thread safety information.


Having just encountered this unusual and undocumented thread safety problem using 2.7.6, I'm wondering if there are other similar lurking thread safety issues that I might only find when the race conditions are just right and my program stops working.

Lisa, please be careful with nosy list.

SilentGhost, msg263977 is spam copied from msg206393 to try to fool people into clicking on the link. I've marked all of these messages from editor-buzzfeed as spam.

From what I can tell, this is a Python 2.7-only bug, and it's not a security issue, so I think we can close the issue as either "wontfix" (because we won't fix it in Python 2) or "fixed" (because it is already fixed in Python 3), depending on your perspective.

As per Paul's suggestion, closing as "won't fix" as this only pertains to Python 2.7 and it will not be changing.