1318810 - Crash in nsPurpleBuffer::VisitEntries<T>

Status: NEW

(Core :: Cycle Collector, defect, P3)

Description

[Sabbath Fan]

This bug was filed from the Socorro interface and is 
report bp-289f9e59-bcf7-4096-a84e-e4d082161119.
=============================================================

Comment 1

[John Hesling [:John99] (NeedInfo me)]

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

Comment 2

[Emil Pasca [:emilpasca]]

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.

Comment 3

[Nathan Froyd [:froydnj]]

Looks like something going wrong in the cycle collector, but the stack reported looks quite odd.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Julien Cristau [:jcristau] (back August 18)]

Mass wontfix for bugs affecting firefox 52.

Comment 6

[User Dderss]

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

Comment 7

[User Dderss]

Attachment: FireFox 56' main tabs process gets automatically restarted after the crash but the browser is still dead, it has to be killed manually via Task Manager.

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.

Comment 8

[Julien Cristau [:jcristau] (back August 18)]

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.

Comment 9

[User Dderss]

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.

Comment 10

[Andrew McCreight (out of office until 8/21) [:mccr8]]

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.

Comment 12

[Marcia Knous [:marcia]]

Updating the affected versions, since this signature is showing up in 64 nightly Fennec of late.

Comment 13

[Chris Peterson [:cpeterson]]

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

Comment 14

[Marcia Knous [:marcia]]

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

Comment 15

[Marcia Knous [:marcia]]

Since Comment 14 it is now up to #3.

Comment 16

[Marcia Knous [:marcia]]

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

Comment 17

[Andrew McCreight (out of office until 8/21) [:mccr8]]

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?

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

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...

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

(I have a theory. testing)

Comment 20

[Chris Peterson [:cpeterson]]

(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).

Comment 21

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

old issue - reset the severity here to let it be in the triage process.