Closed Bug 1315232 Opened 5 years ago Closed 5 years ago

Crash in nsPurpleBuffer::PurpleBlock::VisitEntries<T> with new YouTube UI or LinkedIn

Categories

(Core :: DOM: Core & HTML, defect, P3)

49 Branch
All
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox-esr45 --- unaffected
firefox51 --- unaffected
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- fixed

People

(Reporter: philipp, Assigned: farre)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-be1746f3-b029-4d42-b4a6-d4ab92161104.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsPurpleBuffer::PurpleBlock::VisitEntries<RemoveSkippableVisitor>(nsPurpleBuffer&, RemoveSkippableVisitor&) 	xpcom/base/nsCycleCollector.cpp:1035
1 	xul.dll 	nsPurpleBuffer::RemoveSkippable(nsCycleCollector*, bool, bool, void (*)(void)) 	xpcom/base/nsCycleCollector.cpp:2835
2 	xul.dll 	nsCycleCollector::ForgetSkippable(bool, bool) 	xpcom/base/nsCycleCollector.cpp:2883
3 	xul.dll 	nsCycleCollector_forgetSkippable(bool, bool) 	xpcom/base/nsCycleCollector.cpp:4110
4 	xul.dll 	FireForgetSkippable 	dom/base/nsJSEnvironment.cpp:1245
5 	xul.dll 	CCTimerFired 	dom/base/nsJSEnvironment.cpp:1793
6 	xul.dll 	nsTimerImpl::Fire() 	xpcom/threads/nsTimerImpl.cpp:524
7 	xul.dll 	nsTimerEvent::Run() 	xpcom/threads/TimerThread.cpp:286
8 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1076
9 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp:290
10 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:132
11 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:225
12 	xul.dll 	NS_DispatchToCurrentThread(nsIRunnable*) 	xpcom/glue/nsThreadUtils.cpp:174
13 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp:262
14 	xul.dll 	nsAppStartup::Run() 	toolkit/components/startup/nsAppStartup.cpp:284
15 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp:4297
16 	xul.dll 	XREMain::XRE_main(int, char** const, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp:4424
17 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4515
18 		@0x121d19f

this signature started showing up since firefox 49 builds - on 50.0b this is currently accounting for 0.12% of all crashes. on first sight there are no interesting correlations for this signature...

https://mozilla.github.io/stab-crashes/supergraph.html?s=nsPurpleBuffer%3A%3APurpleBlock%3A%3AVisitEntries%3CT%3E
Another new cycle collector crash.
Component: General → XPCOM
Andrew, do you think this has any higher chance of being fixed than bug 1296631?
Flags: needinfo?(continuation)
(In reply to Andrew Overholt [:overholt] from comment #2)
> Andrew, do you think this has any higher chance of being fixed than bug
> 1296631?

I looked at this, and I have no idea what might be going wrong.
Flags: needinfo?(continuation)
Given comment 3 I'm going to set wontfix for 50 and 51. Still holding out hope for 52 :)
Crash volume for signature 'nsPurpleBuffer::PurpleBlock::VisitEntries<T>':
 - nightly (version 54): 156 crashes from 2017-01-23.
 - aurora  (version 53): 2 crashes from 2017-01-23.
 - beta    (version 52): 156 crashes from 2017-01-23.
 - release (version 51): 425 crashes from 2017-01-16.
 - esr     (version 45): 0 crashes from 2016-08-03.

Crash volume on the last weeks (Week N is from 01-30 to 02-05):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly      61
 - aurora        0
 - beta         72
 - release     212       0
 - esr           0       0       0       0       0       0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #64       #7
 - aurora            #145
 - beta    #72       #48
 - release #98       #58
 - esr
Crash Signature: [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] → [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>]
Crash Signature: [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] → [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots]
A contact of mine has recently brought report bp-d80ef743-7703-4960-8be6-f73062170204 to my attention - looking through search for VisitEntries resulted in a small amount of other users crashing with similar signatures (VisitEntries executing non-code in xul.dll).
(In reply to Bas Timmer from comment #6)
> A contact of mine has recently brought report
> bp-d80ef743-7703-4960-8be6-f73062170204 to my attention - looking through
> search for VisitEntries resulted in a small amount of other users crashing
> with similar signatures (VisitEntries executing non-code in xul.dll).

I get similar crashes in Nightly by visiting YouTube in its experimental (material design) UI. No crashes if I visit YouTube, in a private window in the same profile, using its stable UI.
See also bug 1336762.
#4 topcrash in Windows Nightly build 20170203094345, with 251 occurrences, which is a *lot*. (It's only #4 because that was a bad Nightly build with a couple of other even worse crashes.)
Keywords: topcrash
Crash Signature: [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots] → [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ @0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots]
I can also confirm the constant crashing on the new Youtube UI. In case you needed testcase...
Page refresh/load might not crash and might crash quite randomly. Usually video has time to start playing, but crash happens in few seconds. Also crashes on pages without video, like Subscriptions etc.
This feels like it could be a dupe of something, but I'll take a look.
Assignee: nobody → continuation
How do I enable the new UI? And how can I tell if I have the new UI?

I found some instructions from last year that talk about deleting a cookie and creating a new one but they didn't seem to do anything.
Flags: needinfo?(Fanolian+bugzilla)
(In reply to Andrew McCreight [:mccr8] from comment #11)
> How do I enable the new UI? And how can I tell if I have the new UI?
> 
> I found some instructions from last year that talk about deleting a cookie
> and creating a new one but they didn't seem to do anything.

Please refer to the attached screenshot for the YouTube MD UI.
There is an exit icon on the bottom right corner for quitting the MD UI. The left sidebar is hidden by default. It dims the main content when I open the sidebar.

I do not know how to enable it neither. It was enabled some time ago and I just never quit that (in Firefox; I quit in Chrome and cannot get it back).
I think the UI choice is now tied to my Google account instead of a cookie value. I open YouTube in a new profile and get the standard UI. Once I log in with my Google account, I get the MD UI (and it crahses...) despite having a different value for the cookie VISITOR_INFO1_LIVE from the one in my main profile and an old tutorial [1] I find on the web.

[1]: http://www.theverge.com/2016/5/3/11576016/youtube-material-design-test

Maybe you can ask Google to enable MD UI for a Google account for testing purpose?

Just FYI, bug 1336229 does not fix the YouTube crash bug 1336762 in 2017-02-06 build.
Flags: needinfo?(Fanolian+bugzilla)
Could you use mozregression to narrow it?
(In reply to Krzysztof from comment #13)
> Could you use mozregression to narrow it?

This bug is filed few months ago which predates bug 1313864.
The recent crash spike due to YouTube MD UI is regressed by bug 1313864 but not fixed by bug 1336229.
(In reply to Fanolian from comment #14)
> This bug is filed few months ago which predates bug 1313864.

Thanks for the information. The signature is pretty generic and not very helpful, so let's just make this bug focus on the recent regression, which has actual steps to reproduce.

Andreas, can you look into this? It sounds like it is another regression from bug 1313864.
Assignee: continuation → nobody
Blocks: 1313864
Component: XPCOM → DOM
Flags: needinfo?(afarre)
Summary: Crash in nsPurpleBuffer::PurpleBlock::VisitEntries<T> → Crash in nsPurpleBuffer::PurpleBlock::VisitEntries<T> with new YouTube UI
On it.
Assignee: nobody → afarre
Flags: needinfo?(afarre)
Just wanted to mention that I do not encounter this issue on the Favorites playlist page, but I do on every other page on YouTube.

Also since no one has mentioned it here, the way to get yourself into the beta for the material design YouTube theme, https://www.reddit.com/r/youtube/comments/4yin6w/force_the_new_material_layout_when_logged_in/

I hope this is helpful.
Another note: Unchecking/disabling the autoplay setting (flicking the switch) when on a video page seems to cause the crash more often.

Also, loading a page from the URL bar directly, instead of by clicking a link seems to cause the crash more often.

Both of these are just my personal anecdotes, but maybe it'll be useful.
(In reply to Gabe Tanenhaus from comment #17)
> Just wanted to mention that I do not encounter this issue on the Favorites
> playlist page, but I do on every other page on YouTube.
> 
> Also since no one has mentioned it here, the way to get yourself into the
> beta for the material design YouTube theme,
> https://www.reddit.com/r/youtube/comments/4yin6w/
> force_the_new_material_layout_when_logged_in/
> 
> I hope this is helpful.

Thank you. I can confirm the code "cookie set PREF f6=4" does enable YouTube MD UI in Nightly, even if logged out.
FYI, once you have enabled MD UI and exited the experiment, you can toggle the UI back to MD from https://www.youtube.com/testtube. (The toggle option is hidden when using MD UI.)
See Also: → 1337814
Crash Signature: [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ @0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots] → [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ @0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots] [@ mozilla::CycleCollectedJSContext::JSObjectsTenured]
Summary: Crash in nsPurpleBuffer::PurpleBlock::VisitEntries<T> with new YouTube UI → Crash in nsPurpleBuffer::PurpleBlock::VisitEntries<T> with new YouTube UI or LinkedIn
Depends on: 1337814
See Also: 1337814
Duplicate of this bug: 1336762
Crash Signature: [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ @0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots] [@ mozilla::CycleCollectedJSContext::JSObjectsTenured] → [@ nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ @0x0 | nsPurpleBuffer::PurpleBlock::VisitEntries<T>] [@ nsINode::nsSlots::~nsSlots] [@ mozilla::CycleCollectedJSContext::JSObjectsTenured] [@ nsCycleCollector::ForgetSkippable ]
Duplicate of this bug: 1338050
Some patches have landed from bug 1337814, so hopefully the 2-9 Nightly won't crash like this any more.
At least my limited "testing" on Youtube doesn't crash anymore, so it seems like fixed.
I did some more detailed testing on youtube and the crashes are away so I think we can mark this issue as fixed.
Thanks for testing!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1337862
Target Milestone: --- → mozilla54
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.