Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Description • 9 years ago

Stacks of the main threads for both processes are attached. I think Windows is waiting on the child process to respond to a sync message, but I am not 100% sure. In any case, the child is blocked waiting for the parent and never returns.

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 1 • 9 years ago

(This was with 3/23/15 nightly, x64, build id was 20150323030203)

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 2 • 9 years ago

Oh, and I had been fooling around with TabTip (accessibility app, see bug 1133351, comment 0). The accessibility+e10s warning doorhanger had been visible at some point during the app lifetime, so maybe this is due to accessibility somehow?

	Jim Mathies [:jimm]
	Comment 3 • 9 years ago

(In reply to Ben Turner <unresponsive until 3/30> (use the needinfo flag!) from comment #2)
> Oh, and I had been fooling around with TabTip (accessibility app, see bug
> 1133351, comment 0). The accessibility+e10s warning doorhanger had been
> visible at some point during the app lifetime, so maybe this is due to
> accessibility somehow?

Have you seen this without a11y running? An a11y hang seems pretty plausible since the e10s a11y code Trevor's been adding isn't complete / well tested.

Any STR?

I'm *really* curious about reproducible hangs when running under e10s. We've put mitigation in place to prevent this, but there are probably some corner cases we can get into. Problem is, I've seen zero bugs related to plugin hangs in nightly+e10s so far.

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 4 • 9 years ago

(In reply to Jim Mathies [:jimm] from comment #3)
> Have you seen this without a11y running?

No...

> Any STR?

I just opened a new window and then closed it after a second or two.

	Trevor Saunders (:tbsaunde)
	Comment 5 • 9 years ago

So, from the stacks it looks like the parent sends an async message to the child telling it a window is being deactivated, and then goes off to destroy a window.  In the child while handling that async message saying the window is being deactivated dispatches a sync message to the parent for some cpow thing.  So the child is blocked on the parent answering its message, but I'm not sure why the parent is blocked in NtUserDestroyWindow.  What does that function do?  I suppose this could somehow be related to the fake windows accessibility sometimes creates?

	Jim Mathies [:jimm]
	Comment 6 • 9 years ago

(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> So, from the stacks it looks like the parent sends an async message to the
> child telling it a window is being deactivated, and then goes off to destroy
> a window.  In the child while handling that async message saying the window
> is being deactivated dispatches a sync message to the parent for some cpow
> thing.  So the child is blocked on the parent answering its message, but I'm
> not sure why the parent is blocked in NtUserDestroyWindow.  What does that
> function do?  I suppose this could somehow be related to the fake windows
> accessibility sometimes creates?

NtUserDestroyWindow may be trying to use SendMessage to send an event sync to a native window and the receiving dispatch loop isn't running. Probably because it's blocked in some ipc related WaitForSyncNotify call.

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 7 • 9 years ago

Hopefully this went away (?) with the bug 1149772 fix.

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 8 • 9 years ago

Tumbleweeds. Please reopen if this is still happening.