crash, crashreportid, meta, multiprocess, qawanted, topcrash
1200646, 1238657, 1240542, 1259125, 1289405, 1311869, 1329301, 1333464, 1333605, RunWatchdogShutdownhang, 1375704, 1378276, 1415837, 1421915, 1424451, 1434319, 1435961, 1435962, 1435966, 1437477, 1445312, 1495632, 1266275, 1290280, 1301339, 1301346, 1316867, 1324399, 1324820, 1329300, 1329305, 1339589, 1346161, 1391607, 1399734, 1405290, 1406839, 1408631, 1419488, 1422715, 1434618, 1435960, 1437575
This bug was filed from the Socorro interface and is report bp-3bbe367b-ff88-4040-90de-0567a2160609. ============================================================= new signature in JSStructuredCloneWriter
I had a huge FF session in SafeMode and by exit got this crash, too: https://crash-stats.mozilla.com/report/index/d0758d13-d0c8-4ccf-985b-bf1522160615
This link seems to freeze browser and I just got a 'shut down' kill' crash. https://crash-stats.mozilla.com/report/index/cfd92e66-a5e1-44be-b18d-33b982160625 Running Win10 x64 and Win32 Nighly builds. Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 e10s in 'enabled' Same, goes not responding with e10s 'off' No idea when this started, just noticed today trying to visit: http://www.mayoclinic.org/diseases-conditions/retrograde-ejaculation/basics/definition/con-20030795
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just discovered that it does not Hang with 'Tracking Protection' 'OFF' Options->Privacy: Had it set to 'Always', Flipping to 'Never' stops the hang.
This signature covers a lot of possible issues. It looks like we don't have a bug on it, so this can be the one. Jim, I filed bug 1282580 for the issue you're seeing. The shutdown hang is really a side effect of a different problem (that the site is hanging).
See Also: → bug 1282580
20160629030209 Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0 Nightly 50.0a1 crashed having the same signature as the one from this bug with the following steps: 1. Load http://html.spec.whatwg.org/ 2. Press Ctrl+F to open the Find toolbar 3. Scroll the page up and down 4. Close FF Expected results: The page should be loaded without crashing Actual results: The page is loaded, Find toolbar is not opened,the page is not scrolled and after page is closed Firefox crashes: https://crash-stats.mozilla.com/report/index/e013a326-36b4-4cad-829c-8efc42160630
This is a generic signature, so different steps to cause a crash from this signature should have separate bugs, blocking this bug.
We'll need a multifaceted approach here. Comment 5 isn't really even a bug, exactly. If a web page is doing a lot of work and you quit, then the content process is going to be slow to respond (slower than 5 seconds). It's probably reasonable to increase the timeout to 30 seconds.
Priority: -- → P2
I thought the plan here was to get rid of this entirely by just killing the content process when we didn't need it any more. We cannot afford to let content block shutdown for significant periods of time (5 seconds is already too much in general).
Can I ask something? I have a lots of tabs, so most of the time e.g. last year closing/restarting FireFox took forever (sometimes literally since you would just never see the damn thing going away from the task manager process list no matter for how long you wait), but in recent months there was a change that has finally put a time limit on how long FF can stay in the memory after you commanded exit. Though it is still takes unacceptably long time. Correct me if I am wrong, but from what I understand, there were no fundamental changes in how FF operates, but what was done was literally implementation of a time limit after which FireFox/PluginContainer gets killed no matter what. As result, ever since that change, absolutely every exit/restart I have in FF ends with a crash like this one or of another type of ShutDownKill. Can some please explain why it is impossible to redesign things in a way that would allow FireFox exit/restart ***right away***? Or maybe such development project is already ongoing within Mozilla quarters, and it is supposed to "land" in FF version 55 or something? Thanks in advance.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #8) > I thought the plan here was to get rid of this entirely by just killing the > content process when we didn't need it any more. We cannot afford to let > content block shutdown for significant periods of time (5 seconds is already > too much in general). The problem I realized only recently is with "beforeunload", "unload", and "pagehide" events. Currently, Firefox fires them on shutdown. They can do sync XHRs, so they have observable side effects. Sync XHRs are "deprecated" (although no one seems very hopeful that we'll ever be able to remove them), but the beacon API is new and we would need to support that at shutdown as well (currently I'm not sure if that even works). If we stop firing this stuff at shutdown, we're probably going to break a lot of websites. There's a github issue on the topic  that links to a bunch of Chrome usage counters, and it seems like a lot of sites are using sync XHR in unload (something like 0.3% of web pages as far as I understand the data). I think we could probably make an effort to fire these event listeners but not do any of the other teardown activities associated with destroying a docshell. That might save us a good amount of time.  https://github.com/whatwg/xhr/issues/20#issuecomment-185163375
Setting needinfo to Benjamin in case you have an opinion or ideas on comment 10.
I assumed that shutdown worked like this (and I'm totally terrible for assuming this): * the Firefox UI code knows that we're quitting. ** It triggers beforeunload handlers before we've actually decided to quit, so that we can support the returnValue/confirmation UI. ** Then we trigger the unload (and pagehide?) events as part of closing the Firefox window ** This process also collects any final session restore information * Only after we're finished shutting down the user-visible bits do we trigger the content process to quit ** At this point, the content process shouldn't contain any important user data and in non-leakchecking builds we can just kill it (using TerminateProcess/SIGTERM) ** In leakchecking builds we'd do the full/painful shutdown sequence So you're saying that we don't trigger some of the unload events until we've actually told the content process to quit? That seems like it might be both a UI regression (in case the beforeunload event has quit confirmation prompts) and might cause weird teardown sequence errors in the Firefox UI.
Flags: needinfo?(benjamin) → needinfo?(wmccloskey)
Your description is correct as I understand things, except maybe for when we start the shutdown timer. A typical sequence is: 1. We run "beforeunload" events before everything else. 2. Parent does session restore, which does spin the event loop waiting for the child. But at this point nothing has been closed and this is pretty fast. 3. Parent closes all the windows, which closes all tabs, which causes an async message to be sent to the child asking it to tear down the docshell for that tab. Destroying a docshell fires "unload"/"pagehide" and also frees memory for the tab (DOM, frame tree, etc.). 4. Parent ends up in ContentParent::Observe("xpcom-shutdown"), at which time it asks the child to shut down. If the child fails to shut down after 5 seconds, it kills it. We could introduce more waiting to give the child a chance to finish running its "unload"/"pagehide"/docshell destruction code before we start the 5 second timer in step (4). However, that would defeat the purpose of the timer, since AFAIK step (3) is what takes all the time. When you have 20 tabs and we have to free the memory for all of them as well as handle any sync network requests they make, it can easily take > 5 seconds. To put it another way, once all the docshells are gone, shutting down the content process is trivial (in opt builds). There's a little bit of message traffic with the parent, but basically the child just calls QuickExit. If we want to save time here, I think the best we can do is avoid freeing the DOM/frame tree/whatever else. I'd be interested in how other browsers handle this. I Googled for "firefox shutdown slow" and "chrome shutdown slow". There are a lot more results for Firefox.
Tracking this for 50, seems like a high volume crash good to keep an eye on.
status-firefox50: --- → affected
tracking-firefox50: --- → +
> However, that would defeat the purpose of the timer, since AFAIK step (3) is what takes all the time. How about tearing down tabs 1 by 1 and giving each one a separate timeout. That way a hang can still be detected by the timeout scales with the tabs.
Crash volume for signature 'IPCError-browser | ShutDownKill': - aurora (49): 69120 - beta (48): 805 - release (47): 702 - esr (45): 14 Affected platforms: Windows, Mac OS X, Linux
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox-esr45: --- → affected
(In reply to Bill McCloskey (:billm) from comment #13) > If we want to save time here, I think the best we can do is avoid freeing > the DOM/frame tree/whatever else. I'd be interested in how other browsers > handle this. I Googled for "firefox shutdown slow" and "chrome shutdown > slow". There are a lot more results for Firefox. Andrew do you know who might be able chase this?
Would the idea with this be to, instead of closing all of the windows, trigger the firing of these "beforeunload", doing SessionStore stuff, "unload", and "pagehide" etc. events, and then just kill the child process outright, without performing any of the usual cleanup? (I presume that the child process would QuickExit() itself)
(In reply to Michael Layzell [:mystor] from comment #18) > Would the idea with this be to, instead of closing all of the windows, > trigger the firing of these "beforeunload", doing SessionStore stuff, > "unload", and "pagehide" etc. events, and then just kill the child process > outright, without performing any of the usual cleanup? (I presume that the > child process would QuickExit() itself) Yes. We already avoid application-level cleanup (e.g., XPCOM shutdown) by calling QuickExit. We additionally would like to avoid any docshell-level cleanup we're doing now. Probably the first step, though, is to see how expensive that cleanup is.
¡Hola! Just crashed like this on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0 ID:20160831030224 CSet: 506facea63169a29e04eb140663da1730052db64 Report ID Date Submitted bp-5141c955-afeb-4668-ac9f-c4dcb2160831 31/08/2016 09:31 a.m. https://crash-stats.mozilla.com/signature/?product=Firefox&signature=IPCError-browser%20%7C%20ShutDownKill says there were 35318 in the past week so this one seems to be popular. ¡Gracias! Alex
status-firefox51: --- → affected
After a normal Nightly update, I got a "you have unsubmitted crash reports" infobar. After submitting, I went to about:crashes and saw that it was a crash with this signature (https://crash-stats.mozilla.com/report/index/e9600c03-5f4c-47a8-b33f-39ee72160831). Since the "crash" wasn't actually user-visible in any way, it probably falls under the "not a real bug" scenario, and it was only made evident to me by the existence of the infobar. I've gotten that same infobar a number of times in the last month after updating Nightly, so it wouldn't surprise me if a lot of the crashes reported with this signature are also not otherwise user-visible.
(In reply to Kartikaya Gupta (email:email@example.com) from comment #21) > After a normal Nightly update, I got a "you have unsubmitted crash reports" > infobar. After submitting, I went to about:crashes and saw that it was a > crash with this signature > (https://crash-stats.mozilla.com/report/index/e9600c03-5f4c-47a8-b33f- > 39ee72160831). Since the "crash" wasn't actually user-visible in any way, it > probably falls under the "not a real bug" scenario, and it was only made > evident to me by the existence of the infobar. I've gotten that same infobar > a number of times in the last month after updating Nightly, so it wouldn't > surprise me if a lot of the crashes reported with this signature are also > not otherwise user-visible. Yes, I also get the crash report bar for this signature after updating Nightly. I believe I see it for every Nightly update.
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #21) > Since the "crash" wasn't actually user-visible in any way, it > probably falls under the "not a real bug" scenario, and it was only made > evident to me by the existence of the infobar. It might be a real bug because my YouTube tabs can never remember the time when the playback was stopped before Firefox was closed/restarted -- as FF can never finish the process properly, it always crashes. It is super annoying, and for more than half of a year nothing gets fixed. :( https://crash-stats.mozilla.com/report/index/1ee465ba-fc81-417c-9bc2-8c4852160831 Could
I literally see it every time I restart my Nightly. As Kartikaya said, I never saw it, except for the constant reminders about having unsubmitted crash reports. I've set dom.ipc.tabs.shutdownTimeoutSecs to 30 seconds for now and I don't get those crash reports anymore. I've probably submitted around 200 reports at this point.
I just wanted to ask if it is possible to have an approximate timeline when those FF crashes during exit will go away. Maybe solving this will take a quarter or two, and maybe some one will be assigned to this bug? Thank you in advance.
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
IMO if the content process is blocked by the event handler of unload or pagehide, we should not treat them as shutdown hang. We should think of a way to let the script finish or set a timeout if the sync API is called in such event handlers.
I think there are maybe 36% content shutdown hang kill bugs are from the nested-event-loop handling. I'm not sure but I want to add some annotations in ContentChild to measure this.
2 years ago
Duplicate of this bug: 1308180
2 years ago
See Also: → bug 1286053
2 years ago
See Also: bug 1301464 →
2 years ago
Duplicate of this bug: 1286053
I'm thinking we should start here by increasing the timeout a little bit. I looked through the crash reports today and didn't see too many patterns. We may have a problem with sync messages to the parent that aren't being handled, but it's not certain that that's what's happening.
Based on the patch Kan-Ru added in bug 1301339, out of 5763 ShutDownKill crashes in the last week, we received the Shutdown message in 278 of them (and sent FinishShutdown in 1). So in most cases we never even get a chance to receive the Shutdown message.
(In reply to Bill McCloskey (:billm) from comment #34) > Based on the patch Kan-Ru added in bug 1301339, out of 5763 ShutDownKill > crashes in the last week, we received the Shutdown message in 278 of them > (and sent FinishShutdown in 1). > > So in most cases we never even get a chance to receive the Shutdown message. That's terrible. Maybe shutdown message should not use PContent. It can use PBackground and preempt the current task on content main thread.
(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #35) > (In reply to Bill McCloskey (:billm) from comment #34) > > Based on the patch Kan-Ru added in bug 1301339, out of 5763 ShutDownKill > > crashes in the last week, we received the Shutdown message in 278 of them > > (and sent FinishShutdown in 1). > > > > So in most cases we never even get a chance to receive the Shutdown message. > > That's terrible. Maybe shutdown message should not use PContent. It can use > PBackground and preempt the current task on content main thread. The problem is that we're really supposed to run onunload handlers before we shut down, and I suspect that might be what's taking so long.
Kan-Ru & :billm This volume of the crashes is getting worse in 51 aurora. I this the priority should be adjusted to P1. Can you help to investigate this more?
Priority: P2 → P1
bug 1301346 should get us more insight about onunload handler behavior.
This signature got a lot worse (from 7 crashes a day to 5000 crashes a day) on October 20th. Maybe we can find a regression range. Can the uptime team help?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #39) > This signature got a lot worse (from 7 crashes a day to 5000 crashes a day) > on October 20th. > Maybe we can find a regression range. Can the uptime team help? Looking at the Windows builds at https://dbaron.org/mozilla/crashes-by-build... - Oct 18: 119 - Oct 19: 172 - Oct 20: 1317 - Oct 21: 35 (*) - Oct 22: 889 (*) Ignore this one because the internet was mostly broken that day due to the Dyn DDoS issues and very few users got an updated Nightly. This probably also means that the Oct 20 number is inflated. Judging from this the number of daily crashes went from ~100 to ~1000. Still not good, but not quite as bad as 7 to 5000. I then used the regression window tool at https://dbaron.org/mozilla/crashes-by-build (click on the "Choose regression window" button, then select the Oct 19 and Oct 20 Windows builds) and got this regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d8afaddf9150853b0b68b35b30c1e54a8683e7&tochange=99a239e1866a57f987b08dad796528e4ea30e622 A couple of wild guesses about changes that might have caused this: * Valentin Gosu — Bug 1294719 - Make sure to check mIPCClosed before calling SendRedirect1Begin r=honzab * Aaron Klotz — Bug 1241921: Disable async plugin init regardless of pref; r=jimm Valentin, Aaron, could either of these changes have caused the number of crashes with this signature to have increased by ~10x? If anyone else could look through the regression list, that would be helpful too.
(In reply to Nicholas Nethercote [:njn] from comment #40) > * Aaron Klotz — Bug 1241921: Disable async plugin init regardless of pref; > r=jimm My change could not have done that, as that feature was already disabled by pref. That patch simply hardcoded it. That merge also included the enabling of a11y+e10s on Windows Vista and newer, but I took the liberty of checking the aggregations for that. Only 5% of Windows crashes since October 20 had a11y turned on.
Also if this change 68956648f506 Aaron Klotz — Bug 1241921: Remove CreateWindow* hooks from IPC glue; r=jimm were to cause any problems, they would typically be a spike in stack overflow crashes, which is not what we're seeing here. I'm ruling that one out too.
Drop in crashes between 12th and 21st is possibly from Socorro updates.
From the crash stat report https://goo.gl/VRclPs, there is a big spike in content crashes on Oct 20. From the pushlog between Oct 19 and Oct 20 on aurora branch - https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?startdate=2016-10-19&enddate=2016-10-20, there are coupe of fixes landed in aurora. Just a guess, the fix of bug 1308397 & bug 1304449 might have something to do with this spike. :aklotz, can you help take a look at this?
(In reply to Nicholas Nethercote [:njn] from comment #40) > * Valentin Gosu — Bug 1294719 - Make sure to check mIPCClosed before calling > SendRedirect1Begin r=honzab > could these changes have caused the number of > crashes with this signature to have increased by ~10x? It is possible that some of the crashes in bug 1294719 could have transformed to this one. It would be easy to find out by backing out that patch since it didn't fix the issue. However, based on comment 44 I understand the crash spike also affected aurora. That patch didn't get uplifted.
This doesn't seem to be worse on beta50 than previous releases, and it's getting late in the cycle, wontfix.
status-firefox50: affected → wontfix
(In reply to Gerry Chang [:gchang] from comment #44) > From the crash stat report https://goo.gl/VRclPs, there is a big spike in > content crashes on Oct 20. From the pushlog between Oct 19 and Oct 20 on > aurora branch - > https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?startdate=2016-10- > 19&enddate=2016-10-20, there are coupe of fixes landed in aurora. > > Just a guess, the fix of bug 1308397 & bug 1304449 might have something to > do with this spike. > > :aklotz, can you help take a look at this? Once again, most of those crashes happen with a11y off. Also, if you isolate this signature to Mac OS X, you see a similar spike. I maintain that something else is causing this.
Also those two patches landed on Nightly on Oct 6 and 18, respectively.
There was a spike in both Nightly and Aurora between the Oct 19 and the Oct 20 builds. The only bugs that landed on Oct 19 in both Nightly and Aurora are bug 1305993 and bug 1309198.
By the way, if we look at the graphs for Nightly and Aurora over the past month, it looks like the volume went down on Oct 12 and went back to normal on Oct 21. https://crash-stats.mozilla.com/signature/?release_channel=nightly&signature=IPCError-browser%20%7C%20ShutDownKill&date=%3E%3D2016-09-28T09%3A44%3A27.000Z&date=%3C2016-10-28T09%3A44%3A27.000Z#graphs https://crash-stats.mozilla.com/signature/?release_channel=aurora&signature=IPCError-browser%20%7C%20ShutDownKill&date=%3E%3D2016-09-28T09%3A44%3A27.000Z&date=%3C2016-10-28T09%3A44%3A27.000Z#graphs So it might be what Jonathan said in comment 43. Could you explain what you meant? What Socorro updates?
The period I list is from; https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxaurora Which also has a loss of plugin hangs for the period. You or someone with knowledge of Socorro would have to pinpoint possible change. Just reading commit messages; nothing sticks out to me (don't know the code) to end the loss, bug 1306449 possibly start.
Do you know if something happened that would cause this crash to almost disappear between Oct 12 and Oct 21?
(In reply to Marco Castelluccio [:marco] from comment #52) > Do you know if something happened that would cause this crash to almost > disappear between Oct 12 and Oct 21? Most likely it's because of a bug in the processor. It was introduced in https://github.com/mozilla/socorro/commit/1e180913c464bdfc77602fc26a9cb8bea0c47712 (deployed on Oct 12) And later fixed in https://github.com/mozilla/socorro/commit/c049e63f6bdd0e29acadbe326a68d9890fcd67f0 (deployed on Oct 21) The original bug that found this was: https://bugzilla.mozilla.org/show_bug.cgi?id=1311697 Ludovic noticed it by simply trying to load a crash. Here was a crash that just never succeeded in the processor. We debugged it and found the problem and after deploying that particular crash could be processed again. We thought this was a unique snowflake because it didn't appear to impact the general numbers. (Or we just didn't look at the right range when comparing to previous days) By the way, this was my first processor bug that I had to work on and to avoid this happening in the future we just landed Sentry error handling in the processor. Prior to that, the only way we could find out that certain crashes fail and drop on the floor was if people ssh into the processor nodes and look at the logs. Marco, do you want to start a reprocessing of this date range? If so, talk to me about doing it "gently" and I'll talk to JP about scaling up the infra.
Are you able to reproduce this crash consistently? Do you have steps to reproduce?
After installing FF50 (ok with previous builds), I have this silent crash every day, i.e. when I close firefox at the end of the day.
silent crash because the day after I notice the crash of the day before and so on...never notice before ff50.
(In reply to Marco Castelluccio [:marco] from comment #58) > Are you able to reproduce this crash consistently? Do you have steps to > reproduce? :marco You didn't ask me, but I continue to have several of these crashes each day. For example, Nightly updates itself about mid-morning for me. about:crashes shows me that every updates brings a silent crash, e.g. https://crash-stats.mozilla.com/report/index/cf2a5f92-14da-4e1d-a052-f667a2161217.
I'm not sure if this is of any help, but I've managed to reproduce this crash pretty consistently with the latest m-c  using the following STR: * install the latest version of m-c * set "When nightly starts: Show my window and tabs from last time" under about:preferences#general * opened several tabs/websites in several different custom containers (http://imgur.com/a/zMh60) * closed/restarted fx several times I noticed that the crash started occurring when I tried opening m-c while it was attempting to shutdown initially. After that, I started getting the crash with every fx restart. Crashes: * bp-ff8ee990-5b23-43c3-a3e8-4e48e2161219 * bp-1146cec8-6ed7-42cf-9571-67f872161219 * bp-1384ea42-7d95-46f8-be8b-a3d5e2161219 * bp-e296be83-7fa1-4ede-afb0-455cb2161219  fx53.0a1, buildid: 20161219030207, changeset: 863c2b61bd27
I've managed to narrow down the STR from comment#62 to the following: * install the latest version of m-c * open https://twitter.com/i/moments/810878086774456320 * let one of the random gifs start autoplaying and quickly shutdown FX You'll notice that the shutdown process will hang and will take several seconds for fx to correctly close. I've created a quick video of the STR that I used to reproduce the crash on a brand new m-c installation under macOS 10.12.2: * https://youtu.be/SQ6x5iWVaqg
(In reply to Kamil Jozwiak [:kjozwiak] from comment #63) > I've managed to narrow down the STR from comment#62 to the following: > > * install the latest version of m-c > * open https://twitter.com/i/moments/810878086774456320 > * let one of the random gifs start autoplaying and quickly shutdown FX > > You'll notice that the shutdown process will hang and will take several > seconds for fx to correctly close. > > I've created a quick video of the STR that I used to reproduce the crash on > a brand new m-c installation under macOS 10.12.2: > * https://youtu.be/SQ6x5iWVaqg Can you file a new bug for this (be sure to also attach a link to a crash report)?
(In reply to Marco Castelluccio [:marco] from comment #64) > Can you file a new bug for this (be sure to also attach a link to a crash > report)? Sure :) Created bug#1324820. Let me know if there's anything else that I can help out with.
Could you describe your environment with more details? For example how many tabs were opened when you were closing Firefox? Can you reproduce it with addons disabled? It will help us understand the issue and increase the possibility of getting this fixed. It will help if you have clear steps to reproduce the issue. You can also attach the content from about:support page here or mail it to me directly.
Frank, can you confirm that just now Virtual_ManPL [:Virtual] - (ni? me) fixed this bug? because just now I received some very strange notification per email. https://bugzilla.mozilla.org/show_bug.cgi?id=1331929 https://bugzilla.mozilla.org/show_bug.cgi?id=1311297
(In reply to Yorgos from comment #75) > Frank, can you confirm that just now > Virtual_ManPL [:Virtual] - (ni? me) > fixed this bug? > because just now I received some very strange notification per email. > https://bugzilla.mozilla.org/show_bug.cgi?id=1331929 > https://bugzilla.mozilla.org/show_bug.cgi?id=1311297 Yorgos: I would stay tuned to this bug, and ignore changes to the two bugs you list. It's likely a Mozilla process is simply closing related, inactive, unhelpful or duplicate bugs with no action. Problems like this that many people have generate a lot of noise, so now and then that noise has to be cleared away so it doesn't distract from real work. IMHO, of course.
Exactly it's like Frank Burleigh said. There is no need to create many duplicate bugs about the same issue, as they pollute related bugs in crashlog reports, making hard to speedy find anything in all that useless spam. About bugs I marked as INCOMPLETE, they have noSTR from OP. Reproducible bugs are tracked in blocked bug #1219672. tl;dr - I'm cleaning. (In reply to Yorgos from comment #75) > fixed more like, I marked them as INCOMPLETE
2 years ago
See Also: bug 1286053 →
2 years ago
2 years ago
See Also: → bug 1289405
I pasted the link here because the log (crash report) told me "NEW", not Duplicate ;) otherwise I know that I dont need to post in a duplicate thread!
Virtual: I'm MacOS (OS X), so platform should perhaps be adjusted.
Don't worry, I want all these bugs to be fixed like you too, that's why I'm doing "a little cleaning" (I hope I didn't make any mistakes in this), to help Mozilla developers (or at least I think that I'm helping) getting on track faster without reading duplicates, etc.
2 years ago
status-firefox49: affected → wontfix
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
status-firefox-esr52: --- → affected
Keywords: crash, crashreportid, multiprocess
OS: Windows 7 → All
Hardware: x86 → All
For me it crashes in FF Nightly as well. https://crash-stats.mozilla.com/report/index/3f346172-bf3b-4869-b2d9-7f4ce2170329
Mass wontfix for bugs affecting firefox 52.
status-firefox52: affected → wontfix
Any news to this bug? 278934 crashes of this sig in the last 7 days. https://crash-stats.mozilla.com/signature/?product=Firefox&signature=IPCError-browser%20%7C%20ShutDownKill
status-firefox51: affected → wontfix
status-firefox-esr45: affected → wontfix
status-firefox-esr52: affected → wontfix
Version: 48 Branch → 38 Branch
Any news to this signature? 151515 crashes of this sig in the last 7 days. https://crash-stats.mozilla.com/signature/?product=Firefox&signature=IPCError-browser%20%7C%20ShutDownKill
Signature report for IPCError-browser | ShutDownKill Showing results from 7 days ago Operating System Windows 7 46211 46.5% Windows 10 29388 29.6% Windows 8.1 11219 11.3% 3429 3.5% OS X 10.12 2899 2.9% Windows 8 2313 2.3% OS X 10.11 1097 1.1% Linux 1011 1.0% Product Firefox 54.0a2 37251 37.5% 9618 Firefox 55.0a1 24892 25.1% 10359 Firefox 54.0b4 12112 12.2% 4892 Firefox 54.0b3 4570 4.6% 3417 Firefox 54.0b2 2587 2.6% 1752 Firefox 53.0b99 2576 2.6% 807 Firefox 54.0b1 2139 2.2% 1664 Firefox 54.0a1 1082 1.1% 90 Firefox 53.0b9 1003 1.0% 769 Process Type content 99347 100.0% Uptime Range > 1 hour 46403 46.7% < 1 min 26264 26.4% 15-60 min 12102 12.2% 1-5 min 8937 9.0% 5-15 min 5645 5.7% Architecture x86 61358 61.8% amd64 34564 34.8% 3429 3.5% Flash Version [blank] 95922 96.5% 3429 3.5%
Some crash reports for analyses with FF55.0a1, 64bit, E10s, no add-ons without E10s support, on Win7: 05/10/2017 https://crash-stats.mozilla.com/report/index/1dd66314-efb4-47fd-8811-7ca8e0170510 https://crash-stats.mozilla.com/report/index/5d17cca5-640b-4a27-bdec-1d88c0170510 05/12/2017 https://crash-stats.mozilla.com/report/index/52a8ad06-d3b5-481f-afba-2fcf00170512 https://crash-stats.mozilla.com/report/index/8208673a-b21d-4ffa-8e26-6d3530170512
Yeah, it's going down! :-) 80386 crashes in the last 7 days. When it is also caused by add-ons that are not multiprocessor compatible, whats about deactivate such add-ons in the Developer Edition, too? Developers should be able to set extensions.allow-non-mpc-extensions=true in about:config, too. Also: Is it possible to activate this signature in https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=55.0a1&days=7 again, to have a better eye on it?
I still see a clear relation between a high memory usage of FF after a long time use of GMail, Twitter or Facebook and the ShutDownKills that appear by the restart/shutdown after them. I guess fixing those ShutDownKill-Crashes will reduce the amount of memory FF use over the time it runs and reduce the need to restart FF between work. Here are some sample crash reports from me for analyses produced with FF55.0a1, 64bit, E10s, on Win7 from the last days with different threads: https://crash-stats.mozilla.com/report/index/b232d572-a9a3-45b6-9662-7b9fa0170602 https://crash-stats.mozilla.com/report/index/d9c58c40-fea7-4791-bc8a-b9d930170602 https://crash-stats.mozilla.com/report/index/c1293857-e13c-405b-b682-0bd590170602 https://crash-stats.mozilla.com/report/index/fbc04e1b-03e6-419d-98d6-8e8610170601 https://crash-stats.mozilla.com/report/index/d0a2f888-28f9-4ce7-a4eb-9a9980170601 https://crash-stats.mozilla.com/report/index/12dc4eb5-1fd0-4508-aaf1-4887b0170601 https://crash-stats.mozilla.com/report/index/f683fb5e-4269-405a-949a-ded770170531 https://crash-stats.mozilla.com/report/index/33f8b46d-1035-422b-a2d2-4c6940170531 https://crash-stats.mozilla.com/report/index/3c87e99e-ed67-4140-9b98-3e9a60170531 (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #88) > When it is also caused by add-ons that are not multiprocessor compatible, > whats about deactivate such add-ons in the Developer Edition, too? > Developers should be able to set extensions.allow-non-mpc-extensions=true in > about:config, too. When aurora is not used to ship a alpha2 to developers ATM (is FF54.0a2 while beta is FF54.0bx), what's about shipping FF55.0a1 also as FF55.0a2 to devs ATM? This would force devs to have an eye on webextension/multi-processor-compatibility of there extension. Should I fill a new bug for it? > Also: Is it possible to activate this signature in > https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=55. > 0a1&days=7 again, to have a better eye on it? Should I fill a new bug for it, too?
Here are from me some sample-reports with different threads of new crash-variants from the last days produced with FF55.0a1 latest versions, 64bit with E10s, on Win7, for analyses: https://crash-stats.mozilla.com/report/index/71b28530-6975-41ae-b452-9631d0170604 https://crash-stats.mozilla.com/report/index/eb1b04ea-9ce5-4933-b6c7-968da0170604 https://crash-stats.mozilla.com/report/index/e9b0337f-7962-4e5b-b637-895c20170604 https://crash-stats.mozilla.com/report/index/cf7afd86-decd-4992-9219-01b1b0170604 https://crash-stats.mozilla.com/report/index/d0c24b89-2da5-40ba-b4c8-a7d4d0170604 https://crash-stats.mozilla.com/report/index/840afec8-49d9-4b5c-a254-fca510170604 https://crash-stats.mozilla.com/report/index/38121672-81ea-49d2-bb1f-74c230170604 https://crash-stats.mozilla.com/report/index/cfcf5868-39c7-4d13-8cbd-5b3de0170603 https://crash-stats.mozilla.com/report/index/24729fcb-60b1-41d1-941a-8085d0170603 https://crash-stats.mozilla.com/report/index/fee4ed6f-17a0-4d08-91e4-efb220170603 https://crash-stats.mozilla.com/report/index/471685b3-9853-4b1e-a313-7052a0170603 https://crash-stats.mozilla.com/report/index/f6e32a70-536f-4b1e-8a51-658ff0170602 https://crash-stats.mozilla.com/report/index/34b472ad-b46c-4720-89d3-400ca0170602 Stats are now: 62600 crashes in the last 7 days
a year ago
Duplicate of this bug: 1370202
Here are from me some sample-reports with different threads of new crash-variants from the last days produced with FF55.0a1 latest versions, 64bit with E10s, on Win7, for analyses: https://crash-stats.mozilla.com/report/index/22efc755-adc8-4cd2-ad57-3a9710170612 https://crash-stats.mozilla.com/report/index/2656bddf-bbd3-4ed8-a81b-45ec20170612 https://crash-stats.mozilla.com/report/index/3102b8b2-a3c0-4e91-aee4-518960170611 https://crash-stats.mozilla.com/report/index/300cff78-bc3e-48e7-8ce6-923840170611 Stats are now: 52101 crashes in the last 7 days
Posting links to crash reports is not useful, without any additional information. If somebody is interested in looking at this issue, they can use crash-stats to find reports.
More then 243k crashes with this sig in the last 7 days! Somebody still analyzing them?
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #94) > More then 243k crashes with this sig in the last 7 days! > Somebody still analyzing them? Hey Tobias, this is a very generic signature that corresponds to crashes (less severe than others, as they occur during shutdown) with very different causes. We are monitoring it to see if new crash causes occur (e.g. we recently filed bug 1375704). If you find a reproducible case, please file a new bug and describe the STR. Otherwise, there's no need to keep updating this bug. (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #88) > Also: Is it possible to activate this signature in > https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=55. > 0a1&days=7 again, to have a better eye on it? This is a content process crash, that page shows parent process crashes. If you want a view with this signature in it, you can use https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=55.0a1&days=7&process_type=content.
(In reply to Marco Castelluccio [:marco] from comment #95) > Hey Tobias, [...] > We are monitoring it to see if new crash causes occur (e.g. we recently > filed bug 1375704). > If you find a reproducible case, please file a new bug and describe the STR. > Otherwise, there's no need to keep updating this bug. Marco, thx for you help! If I find a proto_signature (like: proto_signature=~WaitForSyncNotifyWithA11yReentry) I always get and can monitor this way too, can I fill also a bug for it if the proto_signature have many crashes? --- Bugs for IPCError-browser | ShutDownKill: 1339589 NEW --- Firefox on Windows with a11y features enabled crashes on certain websites 1333605 NEW --- Crash in IPCError-browser | ShutDownKill when GCing 1333464 NEW --- Crash in [@ IPCError-browser | ShutDownKill ] caused by the Gecko Profiler 1329305 RESOLVED FIXED Crash in IPCError-browser | ShutDownKill (from GPUVideoImage::GetAsSourceSurface) 1329301 NEW --- Crash in IPCError-browser | ShutDownKill (from GfxInfoBase::GetFeatureStatus) 1329300 RESOLVED FIXED Crash in IPCError-browser | ShutDownKill | I422ToARGBRow_C 1324820 RESOLVED FIXED IPCError-browser | ShutDownKill received when closing FX while a gif is autoplaying from Twitter moments 1324399 NEW --- Shutdown hang crash after DownThemAll! *nightly* extension update 1316867 NEW --- Deterministic crash from cycle collector to js::Scope::traceChildren() when running wasm content 1311869 NEW --- FireFox 49.0.2 Denial Of Service 1290280 VERIFIED FIXED [e10s] Tab crashes on startup 1289405 NEW --- Restarts to update and quits frequently spin for extended/indefinite time after all windows closed 1279293 NEW --- Crash in IPCError-browser | ShutDownKill 1266275 RESOLVED DUPLICATE crash in WaitForSingleObjectEx | WaitForSingleObject | PR_WaitCondVar | mozilla::CondVar::Wait | mozilla::ipc::MessageChannel::WaitForSyncNotify | mozilla::ipc::MessageChannel::Send | mozilla::net::PCookieServiceChild::SendGetCookieString 1259125 NEW --- crash in nsINode::Slots 1240542 NEW --- crash in js::InterpreterActivation::InterpreterActivation 1238657 NEW --- crash in js::frontend::TokenStream::getChar 1219672 NEW --- [meta] e10s related ShutDownKill parent side abort of the content process 1200646 NEW --- crash in DestroyDisplayItemDataForFrames
Summary: Crash in IPCError-browser | ShutDownKill → [meta] Crash in [@ IPCError-browser | ShutDownKill]
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #96) > (In reply to Marco Castelluccio [:marco] from comment #95) > > Hey Tobias, [...] > > We are monitoring it to see if new crash causes occur (e.g. we recently > > filed bug 1375704). > > If you find a reproducible case, please file a new bug and describe the STR. > > Otherwise, there's no need to keep updating this bug. > > Marco, thx for you help! > > If I find a proto_signature (like: > proto_signature=~WaitForSyncNotifyWithA11yReentry) I always get and can > monitor this way too, can I fill also a bug for it if the proto_signature > have many crashes? No, unless you have steps to reproduce or the crash is exploding (that is, if it was low-volume and suddenly became high volume).
a year ago
Duplicate of this bug: 1391607
a year ago
Depends on: 1391607
I have a low-powered AMD Brazos E-350-based laptop (Lenovo x120e) and I get the crash infobar on every restart. Having a fixed value for dom.ipc.tabs.shutdownTimeoutSecs is unreasonable. It should be based on CPU performance.
Depends on: 1399734
Signature report for IPCError-browser | ShutDownKill Showing results from 7 days ago 760,549 Results Windows 7 432449 57.2% ______ 172851 22.8% Windows 10 69528 9.2% Windows 8.1 60316 8.0% Windows 8 11046 1.5% Linux 5114 0.7% OS X 10.12 2499 0.3% OS X 10.11 906 0.1% Windows XP 717 0.1% OS X 10.10 405 0.1% OS X 10.13 343 0.0% OS X 10.9 168 0.0% Windows Vista 141 0.0% OS X 10.7 49 0.0% Windows Server 2003 7 0.0% Product Firefox 58.0a1 29766 3.9% 14975 Firefox 57.0b4 1490 0.2% 770 Firefox 57.0b3 235271 31.1% 58808 Firefox 57.0b0 26731 3.5% 6502 ________ 57.0b0 2 0.0% 2 Firefox 57.0a1 7039 0.9% 3237 Firefox 56.0b99 280748 37.1% 52273 Firefox 56.0b12 72465 9.6% 25662 Firefox 56.0b11 18920 2.5% 5869 Firefox 56.0b10 13566 1.8% 5072 Uptime Range > 1 hour 411879 54.4% < 1 min 142035 18.8% 15-60 min 119670 15.8% 1-5 min 43869 5.8% 5-15 min 39086 5.2% Architecture x86 433124 57.3% _____ 172851 22.8% amd64 150564 19.9% Flash Version [blank] 756524 100.0% 188.8.131.52 12 0.0% 11.8.800.168 1 0.0% 184.108.40.206 1 0.0% 220.127.116.11 1 0.0% Graphics Adapter 0x8086 0x29c2 48514 6.4% 0x8086 0x2e32 43141 5.7% 0x8086 0x0152 39741 5.3% 0x8086 0x0102 34138 4.5% 0x8086 0x2a42 28727 3.8% 0x8086 0x2772 27883 3.7% 0x8086 0x0166 26806 3.5% 0x8086 0x0f31 26451 3.5% 0x8086 0x0046 26235 3.5% 0x8086 0x0116 24699 3.3% 0x8086 0x0a16 23631 3.1%
status-firefox57: --- → affected
status-firefox58: --- → affected
[Tracking Requested - why for this release]: Can this [meta] bug and all of the individual bugs that "depend" on it be tracked for FF58? There are hundreds of thousands of crashes under this signature in the past 7 days often accounting for upwards of 90% of the content crashes per release. It is the #1 Top Crasher for Content crashes. Signature report for IPCError-browser | ShutDownKill Showing results from 7 days ago 962,573 Results [IPCError-browser | ShutDownKill] https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=58.0a1&days=7&process_type=content Top Crashers for Firefox 58.0a1 1 67.52% -6.31% IPCError-browser | ShutDownKill 39573 27710 697 2166 15650 0 2016-05-04 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=57.0b6&days=7&process_type=content Top Crashers for Firefox 57.0b6 1 10.16% new IPCError-browser | ShutDownKill 1978 1490 10 35 585 0 2016-05-04 2 8.12% new IPCError-browser | PBrowserParent::RecvPDocAccessibleConstructor Constructing a top-level PDocAccessible with null COM 1582 1582 0 0 392 0 2017-05-02 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=57.0b5&days=7&process_type=content Top Crashers for Firefox 57.0b5 1 89.81% -32.67% IPCError-browser | ShutDownKill 408160 307837 827 1042 85982 0 2016-05-04 2 2.75% new IPCError-browser | PBrowserParent::RecvPDocAccessibleConstructor Constructing a top-level PDocAccessible with null COM 12480 12461 0 0 609 0 2017-05-02 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=57.0b4&process_type=content Top Crashers for Firefox 57.0b4 1 92.62% -4.41% IPCError-browser | ShutDownKill 268636 201086 592 361 81244 0 2016-05-04 2 2.57% 1.79% IPCError-browser | PBrowserParent::RecvPDocAccessibleConstructor Constructing a top-level PDocAccessible with null COM 7449 7432 0 0 441 0 2017-05-02 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=57.0b3&process_type=content Top Crashers for Firefox 57.0b3 1 89.14% -3.48% IPCError-browser | ShutDownKill 63962 46353 592 676 23462 0 2016-05-04 2 3.96% 2.28% IPCError-browser | PBrowserParent::RecvPDocAccessibleConstructor Constructing a top-level PDocAccessible with null COM 2840 2837 0 0 270 0 2017-05-02 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=57.0b&process_type=content Top Crashers for Firefox 57.0b 1 88.73% -2.55% IPCError-browser | ShutDownKill 742556 555680 2087 3167 194722 0 2016-05-04 2 2.9% 2.43% IPCError-browser | PBrowserParent::RecvPDocAccessibleConstructor Constructing a top-level PDocAccessible with null COM 24304 24265 0 0 1727 0 2017-05-02 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=57.0a1&process_type=content Top Crashers for Firefox 57.0a1 1 73.26% -2.93% IPCError-browser | ShutDownKill 2219 1495 35 155 761 0 2016-05-04 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=56.0.1&_facets_size=300&process_type=content Top Crashers for Firefox 56.0.1 4 4.71% new IPCError-browser | ShutDownKill 23 13 1 1 18 0 2016-05-04 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=56.0&process_type=content Top Crashers for Firefox 56.0 1 45.03% 16.56% IPCError-browser | ShutDownKill 70988 53479 193 79 23645 0 2016-05-04 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=56.0b12&process_type=content Top Crashers for Firefox 56.0b12 1 96.18% 0.89% IPCError-browser | ShutDownKill 29919 23332 141 64 13040 0 2016-05-04 https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=56.0b11&process_type=content Top Crashers for Firefox 56.0b11 1 97.57% -0.59% IPCError-browser | ShutDownKill 12363 9802 49 43 5633 0 2016-05-04
tracking-firefox58: --- → ?
No, this is a meta bug for a signature that's a catch-all for countless issues with separate root causes that aren't actually user-visible, so it's not a candidate for release tracking. We can track specific instances where there's known STR and user impact, but otherwise there's no use.
tracking-firefox58: ? → ---
Duplicate of this bug: 1415837
Duplicate of this bug: 1421915
9 months ago
Depends on: 1437477
You need to log in before you can comment on or make changes to this bug.