Thunderbird startup crash in mozilla::gfx::VsyncSource::GetRefreshTimerVsyncDispatcher



a year ago
11 months ago


(Reporter: wsmwk, Unassigned)


({crash, topcrash-thunderbird})

crash, topcrash-thunderbird

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [startupcrash], crash signature)



a year ago
#1 crash in Thunderbird 56.0b1.  There is some urgency here - I'd like to kill this for beta 2, which hopefully will happen relatively soon.

Might be a core bug - there are firefox crash which also are all startup, and interestingly ONLY esr releases. eg. bp-08074470-ced3-4c3e-8986-7f9ed0170808

all crashes are startup. no history of crash signature on nightly. 
all crash addresses 0x0.  There are several crashes with user email address.

bp-10a8d26a-aa27-4b43-a8bb-544810170808 (dgboles)
0 	xul.dll	mozilla::gfx::VsyncSource::GetRefreshTimerVsyncDispatcher()	gfx/thebes/VsyncSource.cpp:39
1 	xul.dll	mozilla::VsyncRefreshDriverTimer::VsyncRefreshDriverTimer()	layout/base/nsRefreshDriver.cpp:436
2 	xul.dll	CreateVsyncRefreshTimer	layout/base/nsRefreshDriver.cpp:1061
3 	xul.dll	nsRefreshDriver::ChooseTimer()	layout/base/nsRefreshDriver.cpp:1174
4 	xul.dll	nsRefreshDriver::EnsureTimerStarted(nsRefreshDriver::EnsureTimerStartedFlags)	layout/base/nsRefreshDriver.cpp:1388
5 	xul.dll	nsRefreshDriver::AddStyleFlushObserver(nsIPresShell*)	layout/base/nsRefreshDriver.h:167
6 	xul.dll	nsIPresShell::DoObserveStyleFlushes()	layout/base/PresShell.cpp:9781
7 	xul.dll	mozilla::GeckoRestyleManager::PostRestyleEventInternal()	layout/base/GeckoRestyleManager.cpp:690
8 	xul.dll	mozilla::GeckoRestyleManager::PostRestyleEvent(mozilla::dom::Element*, nsRestyleHint, nsChangeHint, mozilla::RestyleHintData const*)	layout/base/GeckoRestyleManager.cpp:727
9 	xul.dll	mozilla::GeckoRestyleManager::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int, nsAttrValue const*)	layout/base/GeckoRestyleManager.cpp:415
10 	xul.dll	mozilla::PresShell::AttributeChanged(nsIDocument*, mozilla::dom::Element*, int, nsIAtom*, int, nsAttrValue const*)	layout/base/PresShell.cpp:4373
11 	xul.dll	nsNodeUtils::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int, nsAttrValue const*)	dom/base/nsNodeUtils.cpp:145
12 	xul.dll	mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const*, nsAttrValue&, unsigned char, bool, bool, bool, nsIDocument*, mozAutoDocUpdate const&)	dom/base/Element.cpp:2631
13 	xul.dll	mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString const&, bool)	dom/base/Element.cpp:2467
14 	xul.dll	mozilla::dom::Element::SetAttribute(nsAString const&, nsAString const&, mozilla::ErrorResult&)	dom/base/Element.cpp:1302
15 	xul.dll	mozilla::dom::ElementBinding::setAttribute	C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/objdir-tb/dom/bindings/ElementBinding.cpp:742
16 	xul.dll	js::AtomizeChars<char16_t>(JSContext*, char16_t const*, unsigned int, js::PinningBehavior)	js/src/jsatom.cpp:499
17 	xul.dll	mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*)	dom/bindings/BindingUtils.cpp:3053
18 	xul.dll	mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*)	dom/bindings/BindingUtils.cpp:3053
19 	xul.dll	js::GetProperty(JSContext*, JS::Handle<JS::Value>, JS::Handle<js::PropertyName*>, JS::MutableHandle<JS::Value>)	js/src/vm/Interpreter.cpp:4406
20 	xul.dll	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)	js/src/vm/Interpreter.cpp:469
21 	xul.dll	InternalCall	js/src/vm/Interpreter.cpp:514
22 	xul.dll	mozilla::dom::GenericBindingGetter(JSContext*, unsigned int, JS::Value*)	dom/bindings/BindingUtils.cpp:2929

Comment 1

a year ago
Not a single piece of C-C code in the call stack. Nothing C-C can fix. Looks like some graphics (gfx) problem. Let's NI a graphics person. Mason, please forward the NI if required.
Flags: needinfo?(mchang)
(In reply to Jorg K (GMT+2) from comment #1)
> Not a single piece of C-C code in the call stack. Nothing C-C can fix. Looks
> like some graphics (gfx) problem. Let's NI a graphics person. Mason, please
> forward the NI if required.

This code hasn't really changed since Firefox ~40 or so. I looked at how this could happen and can't figure it out. We already create gfxPlatform to make sure vsync exists, and we create everything on startup. Unless new is failing here, the pointers shouldn't be null as well since we hold RefPtrs to them forever. Nothing around this code should have changed in ESR 52 as well, unless something else is null since we have 4 null registers at the time of the call. Do we have more than this one user crashing?
Flags: needinfo?(mchang)

Comment 3

a year ago
Yes, multiple people per "installs" column and based on several unique email addresses (which I am able to see)

It would not surprise me if this crash is totally unrelated to gfx, and might even be a manifestation of a previous crash.  I now see, querying the 6 email addresses that have this crash signature, most also have other crash signatures. For example

bp-e0b6c1b1-2f84-4011-bd99-dbbae0170808	2017-08-08 09:46:51 	shutdownhang | NtWaitForAlertByThreadId | RtlSleepConditionVariableCS | SleepConditionVariableCS 

bp-49af134e-b823-4833-a309-0b7760170808	2017-08-08 16:40:14 	morkAtom::AliasYarn  

bp-d6211c93-72ed-444a-a567-db0fe0170728	2017-07-28 23:08:34 	morkRow::GetCell
See Also: → bug 1390002
Did this just start happening in the past week or so? Might be easier to see if something was uplifted this past week instead.
Flags: needinfo?(vseerror)

Comment 5

11 months ago
(In reply to Mason Chang [:mchang] from comment #4)
> Did this just start happening in the past week or so? Might be easier to see
> if something was uplifted this past week instead.

Yes, it is new for Thunderbird, no crashes before 56.0b1 per

However, hard to say if crash is caused by an uplift of a patch from 57.0a1, or a patch that rode the 56 train.  The reason - is no nightly crashes - which is not surprising. Our low number of nightly users often results in crashes not showing in nightly.
Flags: needinfo?(vseerror)

Comment 6

11 months ago
This happened to me today when I updated from Thunderbird 54 to 56b2 via the Help > About > Checking for updates method. After the installation complete I immediately opted to restart Thunderbird, however as it closed a crash report came up. I clicked restart on that and immediately another one came up.

Thankfully a third didn't come up, and I've not had any problems since.

I don't recall getting this issue on my home PC (only my work PC), and both have nearly the same set of extensions. 3 in particular (Enigmail, Lightning, and Provider for Google Calendar) required updating to specific new builds on both PCs.

Comment 7

11 months ago
Adam's crash reports are bp-108e64ce-6c8a-44db-ab13-e4b9f0170815 bp-44d40d25-6469-4eec-b0d3-6beb60170815

another user bp-ba8c463c-8996-4c86-b1f3-de5380170813 reports "when you launch the app directly, tthe main screen of the app draws all empty, none of my tabs are there, and the menus etc are missing, the entire User Interace is unusable."
There's a patch in bug 1390002, which I hope fixes this. The stacks in these crashes make a lot less sense than the Firefox ones.


11 months ago
Depends on: 1390002


11 months ago
See Also: bug 1390002

Comment 9

11 months ago
This is definitely gone with the uplift shipped in Thunderbird beta 3
Last Resolved: 11 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1390002
You need to log in before you can comment on or make changes to this bug.