Deadlock and a rather weird stacktrace

  • Thread starter Vincent van Beveren
  • Start date


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

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\", line 497, in __bootstrap
File "c:\PYTHON26\lib\", line 525, in __bootstrap_inner
File "c:\PYTHON26\lib\", line 477, in run
self.__target(*self.__args, **self.__kwargs)
File "c:\PYTHON26\lib\site-packages\magnum\gui\", line 2558, in __sendDataLoop
File "c:\PYTHON26\lib\", line 256, in wait
File "c:\PYTHON26\lib\", line 497, in __bootstrap
self.__bootstrap_inner() <<===== What?
File "c:\PYTHON26\lib\", line 525, in __bootstrap_inner
File "c:\PYTHON26\lib\site-packages\magnum\subsys\", line 2242, in run
File "c:\PYTHON26\lib\site-packages\magnum\subsys\", line 2214, in updateTask
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\", line 2450, in updateTaskWithConnection
self.updateDataWithConnection(connection, updateAll)
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\", line 2488, in updateDataWithConnection
self.updateVariableData(varDataDict, frozenset(varDataDict))
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\", 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\", line 441, in updateVariableData
File "c:\PYTHON26\lib\site-packages\magnum\subsys\shared\", line 493, in notifyUpdateReport
with self.updateReportCondition:
File "c:\PYTHON26\lib\", line 205, in __enter__
return self.__lock.__enter__()
File "c:\PYTHON26\lib\", 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!

Vincent van Beveren

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




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





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

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 is being called
within 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 You might be
tripping up on one of those.



Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question