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)
Tracking
()
RESOLVED
DUPLICATE
of bug 1056018
Tracking | Status | |
---|---|---|
e10s | m4+ | --- |
People
(Reporter: jimm, Assigned: ally)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
Updated•11 years ago
|
Blocks: old-e10s-m2
Reporter | ||
Updated•10 years ago
|
Blocks: e10s-tests
Updated•10 years ago
|
Assignee: nobody → wmccloskey
Priority: -- → P2
Comment 2•10 years ago
|
||
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:
Comment 5•10 years ago
|
||
Moving old M2 P2 bugs to M4.
Reporter | ||
Comment 8•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: wmccloskey → ally
Assignee | ||
Comment 10•10 years ago
|
||
billm believes this has been fixed by bug 1056018. So let's run the tests and find out
Assignee | ||
Comment 11•10 years ago
|
||
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.
Description
•