Deadlock and a rather weird stacktrace

[Ian]

On 10/03/2011 09:48, Vincent wrote:
> Can nobody explain this? Please. how can a sleep() continue in a
> __bootstrap() ?
>
> Regards,
> Vincent
>
> On 4 feb, 13:39, Vincent van Beveren<V.vanBeve... at rijnhuizen.nl>
> wrote:
>> 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,Vincentvan Beveren
>>
>> ___
>> Ing. V. van Beveren
>> Software Engineer, FOM Rijnhuizen
>> T: +31 (0) 30-6096769
>> E: V.vanBeve... at rijnhuizen.nl
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