Closed
Bug 671196
Opened 13 years ago
Closed 12 years ago
Kill content processes that cause processing errors in the chrome process
Categories
(Core :: IPC, defect, P1)
Core
IPC
Tracking
()
People
(Reporter: cjones, Assigned: cjones)
References
Details
Attachments
(1 file)
1.88 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•13 years ago
|
||
Assignee: nobody → jones.chris.g
Attachment #545610 -
Flags: review?(benjamin)
Updated•13 years ago
|
Attachment #545610 -
Flags: review?(benjamin) → review+
Comment 2•13 years ago
|
||
Mark the tracking flag when this lands: we'll want release drivers to watch the crash stats for Fennec to see if anything bad shows up.
Assignee | ||
Comment 3•13 years ago
|
||
test_process_error.xul (which tests crashing the content process) is failing with this patch, because on windows the content process tries to set up D3D10 layers but they're not supported yet. Something causes a protocol error, and then BAM the content process is killed. It's good that this patch is working, but this reveals a fundamental problem: the kill-on-protocol-error approach isn't going to be able to trigger breakpad on windows. Nor on Mac. So we have to decide between killing a possibly-pwned process but getting crash reports from kills on plain-jane errors, or keeping things the way they are. Will think on't.
Updated•12 years ago
|
blocking-basecamp: --- → +
Comment 5•12 years ago
|
||
Can this land?
Updated•12 years ago
|
Priority: -- → P1
Assignee | ||
Comment 6•12 years ago
|
||
I've been sorting out test failures since Monday.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1cf20feadc1
Comment 7•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in
before you can comment on or make changes to this bug.
Description
•