This bug was filed from the Socorro interface and is report bp-289f9e59-bcf7-4096-a84e-e4d082161119. =============================================================
I note Sabbath fan reports e10s tab crashes and multiple additional crash IDs with differing signatures in their related Sumo thread https://support.mozilla.org/questions/1146910
Based on the crash report I will assign the Core:XPCOM component to this issue and perhaps there's someone with extensive knowledge on this area that might be able to help here.
Status: UNCONFIRMED → NEW
Component: Untriaged → XPCOM
Ever confirmed: true
Product: Firefox → Core
Looks like something going wrong in the cycle collector, but the stack reported looks quite odd.
Priority: -- → P3
Crash volume for signature 'nsPurpleBuffer::VisitEntries<T>': - nightly (version 54): 19 crashes from 2017-01-23. - aurora (version 53): 0 crashes from 2017-01-23. - beta (version 52): 1 crash from 2017-01-23. - release (version 51): 5 crashes from 2017-01-16. - esr (version 45): 492 crashes from 2016-08-10. Crash volume on the last weeks (Week N is from 02-06 to 02-12): W. N-1 W. N-2 W. N-3 W. N-4 W. N-5 W. N-6 W. N-7 - nightly 7 0 - aurora 0 0 - beta 1 0 - release 0 5 0 - esr 46 61 33 34 32 33 33 Affected platform: Windows Crash rank on the last 7 days: Browser Content Plugin - nightly #652 #84 - aurora - beta - release #8670 #4161 - esr #488
Julien, what about newer versions of FireFox? The crash still happens: https://crash-stats.mozilla.com/report/index/9c5a122a-8229-46f3-9d1b-208020171020 One of the suspicious links that might have caused the crash and also causes a weird freeze for me: https://web.archive.org/web/20131015000000*/https://vidstatsx.com/PewDiePie/youtube-channel https://web.archive.org/web/20130928093653/https://vidstatsx.com/PewDiePie/youtube-channel https://web.archive.org/web/20141016222237/https://vidstatsx.com/PewDiePie/youtube-channel
Julien, do you know if FireFox will be upgraded to handle crashes normally? This is not specific to this crash, it is a more general question, but it is highly important as the current architecture is useless for handling the most of the crashes. FireFox's starter process automatically restarts main tabs' process after a crash, but it fails to reconnect to the GUI, so no matter how long you wait you can not control the browser anyway, and you end up killing of the whole thing manually. Obviously, this should not work this way. FireFox should be able to reattach GUI to the main tabs' process it restarts after crashes or, if it is impossible, it has to relaunch itself anew completely, and not force user to use Task Manager.
If you have reproducible steps to reproduce this issue please do post them. Content process crashes aren't supposed to take down the entire browser.
I listed suspect URLs one of which has caused the crash. However, they do not seem to cause the crash on a freshly started browser session, so the crash is not reproducible in a strict way. Could you please look at my crash report I linked to see what could be the cause of the crash and fix it? I have chosen an extensive memory dump detalisation, so you could see a lot from the report. __________________________________________________________ As to the effective death of the entire browser, it happens systematically during totally different crashes in various systems of FireFox, though not in every crash (some are treated right and browsers works fine after autorestarting of the main tabs process). Mind you, the browser is not technically dead, it just becomes infinitely slow to react to anything and fails to render actual tabs' content, as the screenshot I attached shows. What can be done to fix that? Thanks in advance, Julien.
The crash report unfortunately doesn't give any useful information to solve the crash. If you are seeing this regularly, you could try disabling addons. I've seen another CC-related crash somehow from the "It's All Text" addon. As for the other issue of a crash not actually taking down the entire browser, you could try filing a separate bug, maybe in Core:DOM:Content Processes. Again, though, it'll probably be hard to investigate without some way to reproduce the issue. It does sound concerning, though, because issues like that may not get reported to Mozilla, so we can't know how common they are.
Updating the affected versions, since this signature is showing up in 64 nightly Fennec of late.
Flags: needinfo?(nfroyd) → needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.