Re: Deadlock and a rather weird stacktrace

Thu, 10 Mar 2011 04:09:55 -0800 

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...@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...@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












--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to