[Tcl-bugs] [ tktoolkit-Bugs-3529786 ] deadlock between SetFocus and ReadFile

Bugs item #3529786, was opened at 2012-05-25 09:41
Message generated for change (Comment added) made by mrg67
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3529786&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 63. Tk_Win Functions
Group: current: 8.5.11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Gammon (mrg67)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: deadlock between SetFocus and ReadFile

Initial Comment:
My app is a Tcl/Tk front end to a spawned child process. The child is connected to the parent wish process via pipes for stdout and stderr. stdout is fconfigured as nonblocking. fileevents are created to monitor the stdout/err channels and trigger callbacks that read the output and put it in to a scrolling text widgets. The app has one main window and a separate toplevel for a terminal, where the stdout/err output is displayed. The terminal toplevel is transient for the main window and always in front.

So the deadlock occurs when the child process is writing a lot of output down stdout. Everything works fine until I click on the terminal window or somehow cause the focus to shift to it. This triggers a WM_SETFOCUS and WM_ACTIVATE messages to be sent. I believe it is during the processing of these that the deadlock occurs. When the deadlock happens the main thread is nearly always stuck under a SetFocus call or DispatchMessage. The pipereader thread is  stuck under ReadFile. Both threads stacks end at a call to KeWaitForMultipleObjects, so I'm guessing they are waiting for locks from each other.

I've attached the full stacks for the main thread in the SetFocus case and DispatchMessage case, and the stack for the pipereader thread.

I've been trying to spot the cause of the deadlock for days now under the debugger. I can't see what could be shared between the two threads to cause the deadlock. I know I haven't attached enough to reproduce this, but my app is rather large and it would take a while to cut it down. At the moment I'm happy to try to locate and fix this deadlock myself, but i've really run out of places to look. Hopeing someone could point me at a few things that might be behind this.

I've also reproduced this using a 8.3 build of Tcl/Tk so it looks like it may have been here for a while.

It is timing related because if I slow down the output from the child process then I can't trigger the deadlock.

Thanks
Mark

----------------------------------------------------------------------

>Comment By: Mark Gammon (mrg67)
Date: 2012-05-26 00:44

Message:
another way I can reproduce this deadlock is to use the tcl console to
execute a "focus -force" on my terminal toplevel window. the main thread
stack looks similar to the SetFocus one I attached, i.e. its stuck under a
SetFocus call.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3529786&group_id=12997

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Tcl-Bugs mailing list
Tcl-Bugs@...
https://lists.sourceforge.net/lists/listinfo/tcl-bugs