Debugging Spyder multithreading
63 views
Skip to first unread message
anatoly techtonik
Mar 17, 2012, 12:32:54 PM3/17/12
to spyd...@googlegroups.com
Hi everyone,
I've tried to debug issues with "struct.error: unpack requires a string argument of length 4" I experience on my machine (http://code.google.com/p/spyderlib/issues/detail?id=113#c6). So I've inserted a lot of debug statements all over bsdsocket.debug.diff - I don't remember the exact reason why I chose to write debug info to file - probably printing caused a deadlock.
Anyway, the corresponding diff for debugging bsdsocket is in attach, and instead of solving my issue I've run into a bigger problem - with this diff applied Spyder freezes after several seconds after editor becomes operational. I suspect this happens when object inspector fires, but I am not sure.
I've debugged deadlock using the method I've just described at http://code.google.com/p/spyderlib/wiki/HowToDebugDeadlock and it seems that the problem is that in bsdsocket.communicate() something fails to respond to socket read, probably waiting for a lock.
I could dig further, but the thing that bugs me most is that even if it is a race condition - it is 100% time repeatable with debug patch turned on, and doesn't appear without it. I need some help from the experts in threading to answer if a file I/O writes to the single debug log file from multiple threads can be the reason for the proactive heisenbug deadlock?
--
anatoly t.
I've tried to debug issues with "struct.error: unpack requires a string argument of length 4" I experience on my machine (http://code.google.com/p/spyderlib/issues/detail?id=113#c6). So I've inserted a lot of debug statements all over bsdsocket.debug.diff - I don't remember the exact reason why I chose to write debug info to file - probably printing caused a deadlock.
Anyway, the corresponding diff for debugging bsdsocket is in attach, and instead of solving my issue I've run into a bigger problem - with this diff applied Spyder freezes after several seconds after editor becomes operational. I suspect this happens when object inspector fires, but I am not sure.
I've debugged deadlock using the method I've just described at http://code.google.com/p/spyderlib/wiki/HowToDebugDeadlock and it seems that the problem is that in bsdsocket.communicate() something fails to respond to socket read, probably waiting for a lock.
I could dig further, but the thing that bugs me most is that even if it is a race condition - it is 100% time repeatable with debug patch turned on, and doesn't appear without it. I need some help from the experts in threading to answer if a file I/O writes to the single debug log file from multiple threads can be the reason for the proactive heisenbug deadlock?
--
anatoly t.
Reply all
Reply to author
Forward
0 new messages