[meta] e10s related ShutDownKill parent side abort of the content process
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
Tracking | Status | |
---|---|---|
e10s | - | --- |
firefox41 | --- | wontfix |
firefox42 | --- | wontfix |
firefox43 | --- | wontfix |
firefox44 | --- | wontfix |
firefox45 | --- | wontfix |
firefox46 | --- | wontfix |
firefox47 | --- | wontfix |
firefox48 | --- | wontfix |
firefox49 | --- | wontfix |
firefox-esr38 | --- | wontfix |
firefox-esr45 | --- | wontfix |
fennec | - | --- |
firefox50 | - | wontfix |
firefox51 | - | wontfix |
firefox52 | - | wontfix |
firefox-esr52 | --- | wontfix |
firefox53 | --- | wontfix |
firefox54 | --- | affected |
firefox55 | --- | affected |
firefox56 | --- | affected |
firefox68 | --- | affected |
firefox69 | --- | affected |
firefox70 | --- | affected |
People
(Reporter: BesTo, Unassigned)
References
(Depends on 3 open bugs, )
Details
(Keywords: crash, meta, topcrash, Whiteboard: e10st?)
Crash Data
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 2•9 years ago
|
||
Reporter | ||
Comment 3•9 years ago
|
||
Reporter | ||
Comment 4•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 5•9 years ago
|
||
Reporter | ||
Comment 6•9 years ago
|
||
Reporter | ||
Comment 7•9 years ago
|
||
Reporter | ||
Comment 8•9 years ago
|
||
Reporter | ||
Comment 9•9 years ago
|
||
Reporter | ||
Comment 10•9 years ago
|
||
Reporter | ||
Comment 11•9 years ago
|
||
Reporter | ||
Comment 12•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 13•9 years ago
|
||
Reporter | ||
Comment 14•9 years ago
|
||
Reporter | ||
Comment 15•9 years ago
|
||
Reporter | ||
Comment 16•9 years ago
|
||
Reporter | ||
Comment 17•9 years ago
|
||
Updated•9 years ago
|
Comment 19•9 years ago
|
||
Comment 20•9 years ago
|
||
Comment 21•9 years ago
|
||
Comment 22•9 years ago
|
||
Updated•9 years ago
|
Updated•9 years ago
|
Comment 23•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 24•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 25•9 years ago
|
||
Reporter | ||
Comment 26•9 years ago
|
||
Reporter | ||
Comment 27•9 years ago
|
||
Comment 28•9 years ago
|
||
Comment 29•9 years ago
|
||
Comment 30•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 31•9 years ago
|
||
Reporter | ||
Comment 32•9 years ago
|
||
Reporter | ||
Comment 33•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Updated•9 years ago
|
Reporter | ||
Comment 34•9 years ago
|
||
Reporter | ||
Comment 35•9 years ago
|
||
Comment 37•8 years ago
|
||
Reporter | ||
Comment 38•8 years ago
|
||
Reporter | ||
Comment 39•8 years ago
|
||
Reporter | ||
Comment 40•8 years ago
|
||
Comment 41•8 years ago
|
||
Reporter | ||
Comment 43•8 years ago
|
||
Reporter | ||
Comment 44•8 years ago
|
||
Comment 46•8 years ago
|
||
Updated•8 years ago
|
Comment 47•8 years ago
|
||
Updated•8 years ago
|
Updated•8 years ago
|
Reporter | ||
Comment 48•8 years ago
|
||
Reporter | ||
Comment 49•8 years ago
|
||
Comment 50•8 years ago
|
||
Comment 52•8 years ago
|
||
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 65•8 years ago
|
||
Reporter | ||
Updated•8 years ago
|
Reporter | ||
Updated•8 years ago
|
Reporter | ||
Updated•7 years ago
|
Comment 66•7 years ago
|
||
Reporter | ||
Comment 67•7 years ago
|
||
Reporter | ||
Comment 68•7 years ago
|
||
Comment 69•7 years ago
|
||
Reporter | ||
Comment 70•7 years ago
|
||
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Comment 71•7 years ago
|
||
Comment 72•7 years ago
|
||
Updated•6 years ago
|
Comment 74•6 years ago
|
||
¡Hola!
Updated the 68 flag as it is overly represented on https://crash-stats.mozilla.com/signature/?product=Firefox&signature=IPCError-browser%20%7C%20ShutDownKill and I keep getting it pretty often on a regularly updated Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0 ID:20190407214820 :
Submitted Crash Reports
Report ID Date Submitted
bp-d224077b-5f16-4890-9fb7-a3c180190406 4/6/2019, 9:00 AM
bp-b46c5521-4432-4f0c-b4a1-59dda0190406 4/6/2019, 9:00 AM
bp-59551acc-1369-4b27-b8d3-a05c60190404 4/4/2019, 2:14 PM
bp-47093999-e511-4c53-b388-38b100190404 4/4/2019, 2:14 PM
bp-1992ada7-f035-4e31-b9a8-04e190190404 4/4/2019, 2:14 PM
bp-633be6f7-a514-4b87-a3f2-bceed0190404 4/4/2019, 2:14 PM
bp-78429d76-3e63-486d-b25b-f29c20190404 4/4/2019, 9:08 AM
bp-b0291385-a092-4957-9524-10d830190404 4/4/2019, 9:08 AM
bp-db45ce5b-e475-4055-9860-4fd350190404 4/4/2019, 9:08 AM
bp-95deaa46-35e3-423c-b140-efd8f0190402 4/2/2019, 6:05 PM
bp-2f7630d5-d696-4a58-81aa-baf380190402 4/2/2019, 8:41 AM
bp-988ed779-33fb-42d4-affc-a7d720190401 4/1/2019, 9:32 AM
bp-db5537be-e415-4dc9-9c1d-da7930190401 3/31/2019, 7:41 PM
bp-5b3b0fe5-df86-4e93-9d55-4f3060190401 3/31/2019, 7:41 PM
bp-b0dd27b4-0113-4f06-a77f-64c7b0190401 3/31/2019, 7:41 PM
bp-2164c3c6-05ae-48df-a812-5d7520190401 3/31/2019, 7:41 PM
bp-d9f7f1ea-a327-49b9-815f-d9f000190401 3/31/2019, 7:41 PM
bp-3e912571-e160-44f4-b58b-3353a0190401 3/31/2019, 7:41 PM
bp-2eb6cc15-6668-4980-9e84-f993d0190401 3/31/2019, 7:41 PM
bp-01e50d87-6586-4b3d-8369-eefa80190401 3/31/2019, 7:41 PM
bp-3f00a4f3-34b7-408f-b7bc-dfd4f0190401 3/31/2019, 7:41 PM
bp-3d96c578-e8ed-4c9f-b2b7-9f7d90190401 3/31/2019, 7:41 PM
bp-e1fab802-0c5a-40af-94c5-e87e40190401 3/31/2019, 7:41 PM
bp-ce215f00-b494-44bd-b1d5-ba26b0190401 3/31/2019, 7:41 PM
bp-74678893-97ec-4987-9f22-0af560190401 3/31/2019, 7:41 PM
bp-f71f6045-0952-43e7-b46b-b20ee0190401 3/31/2019, 7:41 PM
bp-d0bfde86-5449-44be-b5b8-9d1660190401 3/31/2019, 7:41 PM
bp-3792ea42-3e10-495d-a5df-0e8cb0190401 3/31/2019, 7:41 PM
bp-c3a27b02-3fcd-4d62-b96c-132720190401 3/31/2019, 7:41 PM
bp-acd994a5-3b08-419e-ac8d-e389d0190401 3/31/2019, 7:40 PM
bp-f5e8ff43-19f0-45f8-8ff7-5c0a10190401 3/31/2019, 7:40 PM
bp-097a034e-aa17-4b3a-9a75-c596d0190401 3/31/2019, 7:40 PM
Please do ni? me if there's anything worth collecting from my system.
¡Gracias!
Alex
Updated•6 years ago
|
Updated•6 years ago
|
Comment 79•6 years ago
|
||
Is there something we can do here given the graph shows a clear spike around March 18-20th that hasn't gone away so far?
Comment 80•6 years ago
|
||
Is there something we can do here given the graph shows a clear spike around March 18-20th that hasn't gone away so far?
Looking at a random sampling of stacks, they're all over the place so there's nothing in particular standing out.
Comment 81•6 years ago
|
||
ShutDownKill
is part of ContentParent
and means that a content process didn't finish exiting in time; by default the timeout is 5 seconds.
Maybe the timeout should be increased, but in any case this belongs to the DOM content process component.
Comment 82•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #79)
Is there something we can do here given the graph shows a clear spike around March 18-20th that hasn't gone away so far?
That date is the release of Firefox 66. We upped the content processes to 8 in this release. Which could increase the amount of time it takes for Firefox to shut down cleanly.
Comment 83•6 years ago
|
||
Two things: when I landed the fix for bug 1498942 I made a mistake that caused this signature to drop almost to zero. That was unintended and it masked it for months unfortunately. The proper fix landed in bug 1536850 which should have made the volume drop a bit leaving only valid crashes afterwards.
That being said I think that we might want to increase the timeout before we kill content processes and here's why: while we have a timer for every content process we're trying to shut down they're all initialized almost at once. If the user machine is loaded or has a small number of cores then the process will be almost serialized, with one content process not initiating shutdown before the previous one has completed, but the timers will all tick together nonetheless. Because of this since we doubled the number of content processes we might want to increase the timeout as well.
Updated•5 years ago
|
Comment 84•5 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #83)
Two things: when I landed the fix for bug 1498942 I made a mistake that caused this signature to drop almost to zero. That was unintended and it masked it for months unfortunately. The proper fix landed in bug 1536850 which should have made the volume drop a bit leaving only valid crashes afterwards.
That being said I think that we might want to increase the timeout before we kill content processes and here's why: while we have a timer for every content process we're trying to shut down they're all initialized almost at once. If the user machine is loaded or has a small number of cores then the process will be almost serialized, with one content process not initiating shutdown before the previous one has completed, but the timers will all tick together nonetheless. Because of this since we doubled the number of content processes we might want to increase the timeout as well.
Great idea. Has anything been done on this?
Updated•4 years ago
|
Comment 85•4 years ago
|
||
(In reply to Worcester12345 from comment #84)
Great idea. Has anything been done on this?
No, not yet.
Comment 86•4 years ago
|
||
I'm a bit confused about what to do with this bug. We've been using bug 1279293 to track the signatures so I'm tempted to duplicate against that one. Additionally the [@ nsFrameLoader::DoSendAsyncMessage]
signature has nothing to do with content process ShutDownKill crashes. It's a real crash that should be addressed separately and I'm not sure why it was added here.
Comment 87•4 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•