The default bug view has changed. See this FAQ.

Kill content processes that cause processing errors in the chrome process

RESOLVED FIXED in mozilla17

Status

()

Core
IPC
P1
normal
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: cjones, Assigned: cjones)

Tracking

(Blocks: 1 bug)

Trunk
mozilla17
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

Comment hidden (empty)
Created attachment 545610 [details] [diff] [review]
Kill content processes that cause processing errors in the chrome process
Assignee: nobody → jones.chris.g
Attachment #545610 - Flags: review?(benjamin)
Attachment #545610 - Flags: review?(benjamin) → review+
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.
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.
Darnit, I forget we never landed this.
Blocks: 746280
Blocks: 778025
Depends on: 778067
blocking-basecamp: --- → +

Comment 5

5 years ago
Can this land?

Updated

5 years ago
Priority: -- → P1
I've been sorting out test failures since Monday.

https://hg.mozilla.org/integration/mozilla-inbound/rev/d1cf20feadc1
https://hg.mozilla.org/mozilla-central/rev/d1cf20feadc1
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.