Closed Bug 1010737 Opened 11 years ago Closed 10 years ago

Windows tests that use CPOWs when clicking buttons crash

Categories

(Core :: IPC, defect, P2)

x86_64
Windows 7
defect

Tracking

()

RESOLVED DUPLICATE of bug 1056018
Tracking Status
e10s m4+ ---

People

(Reporter: jimm, Assigned: ally)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached file win32 stack (deleted) —
Spun off from bug 691601 - stack attached. When a browser mochitest invokes a click handler on a button, focus changes and the puppet widget attempts to sync request some IME related information. The ipc channel aborts on this sync call within a sync call in the child process.
Blocks: e10s-tests
Assignee: nobody → wmccloskey
Priority: -- → P2
I see this happening while trying to run: ./mach mochitest-browser browser/base/content/test/chat/browser_focus.js --e10s 127 INFO [Child 52029] ###!!! ABORT: sync messages forbidden while handling urgent message: file /Users/mwargers/mozilla-central/ipc/glue/MessageChannel.cpp, line 1739 128 INFO ###!!! ERROR: Potential deadlock detected:
Moving old M2 P2 bugs to M4.
Move old M2's low-priority bugs to M6 milestone.
oops: old M2 P2 bugs should have been moved to new M4 milestone, not M6.
Hey bill, I'm curious how bug 1049879 allows us to skip over this? With a cpow on the stack and asserting sync outcall, I'm curious how we adjust priorities here to avoid the assert.
Flags: needinfo?(wmccloskey)
We need to raise the priority of IME messages to "urgent". That's one level above what CPOW messages are sent at (which is "high"). That means that the parent will handle the IME message while it's waiting for the CPOW response. The general rule now for avoiding these assertions is that you can only send messages of higher priority than the one you're currently handling. For messages of "high" priority, we also allow same-priority nesting.
Flags: needinfo?(wmccloskey)
Assignee: wmccloskey → ally
billm believes this has been fixed by bug 1056018. So let's run the tests and find out
tests run. Under e10s & non e10s both fail with an identical series of "Uncaught Exception TypeError: Promise.defer is not a function" No aborts, no stacks. Maybe some one should re-enable the test in browser.ini?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: