Open Bug 1318810 Opened 6 years ago Updated 1 year ago

Crash in nsPurpleBuffer::VisitEntries<T>


(Core :: XPCOM, defect, P3)

50 Branch
Windows 10



Tracking Status
firefox-esr45 --- affected
firefox51 --- affected
firefox52 --- wontfix
firefox54 --- affected
firefox62 --- affected
firefox64 --- affected
firefox67 --- affected
firefox68 --- affected


(Reporter: ledzepiscool, Unassigned)



Crash Data


(1 file)

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
Component: Tabbed Browser → Untriaged
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.
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
Mass wontfix for bugs affecting firefox 52.
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.
Flags: needinfo?(jcristau)
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.
Duplicate of this bug: 1495526
Updating the affected versions, since this signature is showing up in 64 nightly Fennec of late.

We see the related nsPurpleBufferEntry::Swap signature in ARM64 Fennec 67 Nightly.

Crash Signature: [@ nsPurpleBuffer::VisitEntries<T>] → [@ nsPurpleBuffer::VisitEntries<T>] [@ nsPurpleBufferEntry::Swap ]

This has moved up to #6 top crash on 67 Fennec nightly.

Since Comment 14 it is now up to #3.

Nathan: Any idea why this might have started happening more regularly in Fennec nightly? In the last week we have 78 crashes/77 installs.

Flags: needinfo?(nfroyd)

I'm not really sure what is going on with this. My first instinct is that there's memory corruption in some other object that we're tracing, but the actual line we're crashing on doesn't actually involve that. This code has some kind of special case for objects being added during iteration. Maybe something is going wrong with that?

Flags: needinfo?(nfroyd) → needinfo?(bugs)

Hmm, Android crashes happen in a different place, and they are about snowwhite freeing. The desktop crashes are about forget skippable.

Is some destructor doing evil things...

Flags: needinfo?(bugs)

(I have a theory. testing)

Flags: needinfo?(bugs)
Flags: needinfo?(bugs)

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #16)

Nathan: Any idea why this might have started happening more regularly in Fennec nightly? In the last week we have 78 crashes/77 installs.

Fennec Nightly builds are now PGO'd as of March 29 (bug 1535364). That might explain random problems with destructors doing the wrong thing.

95% of nsPurpleBufferEntry::Swap crashes are ARM64 Fennec, which was published on the Nightly channel on January 15 (bug 1368484).

QA Whiteboard: qa-not-actionable
You need to log in before you can comment on or make changes to this bug.