Deadlock and a rather weird stacktrace

[Vincent van Beveren]

Hi everyone,

I'm currently working on a multithreaded GUI system in Python 2.6. In this system I use conditions to coordinate synchronization. However, one condition suddenly locks, without any cause. As a last resort I have written a small routine to dump all the stack traces.

def dumpAllStacks(self):
for threadId, stack in sys._current_frames().items():
print "Thread with Id: %s" % threadId
traceback.print_stack(stack)


When the system is dead-locked, I invoke this method. One stack-trace strikes me as odd:

Thread with Id: 1568
File "c:\PYTHON26\lib\threading.py", line 497, in __bootstrap
self.__bootstrap_inner()
File "c:\PYTHON26\lib\threading.py", line 525, in __bootstrap_inner
self.run()
File "c:\PYTHON26\lib\threading.py", line 477, in run
self.__target(*self.__args, **self.__kwargs)
File "c:\PYTHON26\lib\site-packages\magnum\gui\autogui.py", line 2558, in __sendDataLoop
self.__sendDataCondition.wait(1)
File "c:\PYTHON26\lib\threading.py", line 256, in wait
_sleep(delay)
File "c:\PYTHON26\lib\threading.py", line 497, in __bootstrap
self.__bootstrap_inner() <<===== What?
File "c:\PYTHON26\lib\threading.py", line 525, in __bootstrap_inner
self.run()
File "c:\PYTHON26\lib\site-packages\magnum\subsys\__init__.py", line 2242, in run
self.updateTask()
File "c:\PYTHON26\lib\site-packages\magnum\subsys\__init__.py", line 2214, in updateTask
self.statusServerModule.updateTaskWithConnection(self.statusServerConnection)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\modules.py", line 2450, in updateTaskWithConnection
self.updateDataWithConnection(connection, updateAll)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\modules.py", line 2488, in updateDataWithConnection
self.updateVariableData(varDataDict, frozenset(varDataDict))
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\modules.py", line 796, in updateVariableData
self.cmdMgr.updateVariableData(self.moduleId, varDataDict, forceVarIdSet) # after this varMgr makes deepcopy
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\managers.py", line 441, in updateVariableData
self.notifyUpdateReport(updatedData)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\managers.py", line 493, in notifyUpdateReport
with self.updateReportCondition:
File "c:\PYTHON26\lib\threading.py", line 205, in __enter__
return self.__lock.__enter__()
File "c:\PYTHON26\lib\threading.py", line 121, in acquire
rc = self.__block.acquire(blocking)

Can someone tell me how the sleep of one thread can continue as the 'run' of another? Is this normal? Thanks in advance!

Regards,
Vincent van Beveren

___
Ing. V. van Beveren
Software Engineer, FOM Rijnhuizen
T: +31 (0) 30-6096769
E: (e-mail address removed)

 

[Vincent]

Can nobody explain this? Please. how can a sleep() continue in a
__bootstrap() ?

Regards,
Vincent

 

[Ian]

Can nobody explain this? Please. how can a sleep() continue in a
__bootstrap() ?

Regards,
Vincent

Hi Vincent,

I can't explain it, - I am no expert - but I did have some thoughts that
I put forward anyway.

It would appear from the stack trace that self.run() is being called
within self.run(). Did you perhaps start a third thread from within a
second thread?

The first thread is the only one with a stack at start-up, and therefore
it has to be the thread that sets up the stack swapping needed for
multi-threading. If a background thread later starts to create threads,
it is doing so from an unusual situation, and its stack could result in
the sort of double run() stack you see above.

I don't think it matters - the thread will die or return to the pool
when its run() exits, and the extra stack is used only by the creating
thread, and
not the new threads.

It might also be that anything above the first run() call is reported
incorrectly when dumped from another thread.

Have you checked the caveats at the bottom of
http://docs.python.org/library/thread.html#module-thread You might be
tripping up on one of those.

Regards

Ian