Closed Bug 1257112 Opened 8 years ago Closed 8 years ago

crash in mozilla::gfx::UserData::Add

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
38 Branch
Platform:
x86
Windows
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
thunderbird_esr38 --- wontfix

People

(Reporter: sotaro, Unassigned)

References

Details

(4 keywords, Whiteboard: [regression:TB38.3.0][gfx-noted][tbird topcrash])

Crash Data

No longer depends on: 1222487
See Also: → 1222487
This is currently the #6 crash signature in Thunderbird 38.7.2 accounting for 1.12% overall. This is not exclusively a Thunderbird crash but volume seems to be much worse in Thunderbird 38.* than either Thunderbird 45.*, Firefox, or Fennec.
>     Firefox 45.0.2:  140 crashes [  2.2 crashes per 1M users]
>      Fennec 45.0.2:   19 crashes [  3.5 crashes per 1M users]
> Thunderbird 38.7.2: 1343 crashes [420.8 crashes per 1M users]
>   Thunderbird 45.0:    4 crashes [  7.8 crashes per 1M users]

Platform:
This appears to be 100% isolated to Windows 32-bit with Windows 7 at 55% and Windows 10 at 28%.

Devices:
There is no strong correlation to any particular device/driver combination.
status-thunderbird_esr38: --- → affected
tracking-thunderbird_esr38: --- → ?
OS: Windows NT → Windows
Here is a stack from one of the crashes:
0 	xul.dll 	mozilla::gfx::UserData::Add(mozilla::gfx::UserDataKey*, void*, void (*)(void*)) 	gfx/2d/UserData.h
1 	xul.dll 	nsDeviceContext::CreateRenderingContext() 	gfx/src/nsDeviceContext.cpp
2 	xul.dll 	PresShell::CreateReferenceRenderingContext() 	layout/base/nsPresShell.cpp
3 	xul.dll 	PresShell::DoReflow(nsIFrame*, bool) 	layout/base/nsPresShell.cpp
4 	xul.dll 	PresShell::ProcessReflowCommands(bool) 	layout/base/nsPresShell.cpp
5 	xul.dll 	PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) 	layout/base/nsPresShell.cpp
6 	xul.dll 	PresShell::FlushPendingNotifications(mozFlushType) 	layout/base/nsPresShell.cpp
7 	xul.dll 	nsPrintEngine::ReflowDocList(nsPrintObject*, bool) 	layout/printing/nsPrintEngine.cpp
8 	xul.dll 	nsPrintEngine::InitPrintDocConstruction(bool) 	layout/printing/nsPrintEngine.cpp
9 	xul.dll 	nsPrintEngine::Observe(nsISupports*, char const*, wchar_t const*) 	layout/printing/nsPrintEngine.cpp
10 	xul.dll 	nsPrintProgress::DoneIniting() 	embedding/components/printingui/win/nsPrintProgress.cpp
11 	xul.dll 	NS_InvokeByIndex 	xpcom/reflect/xptcall/md/win32/xptcinvoke.cpp
12 	xul.dll 	DefinePropertyOrElement 	js/src/vm/NativeObject.cpp
13 	xul.dll 	SetInterruptCallback 	js/xpconnect/src/XPCShellImpl.cpp
14 	xul.dll 	js::NewFunctionWithProto(js::ExclusiveContext*, JS::Handle<JSObject*>, bool (*)(JSContext*, unsigned int, JS::Value*), unsigned int, JSFunction::Flags, JS::Handle<JSObject*>, JS::Handle<JSAtom*>, JS::Handle<JSObject*>, js::gc::AllocKind, js::NewObjectKind) 	js/src/jsfun.cpp
15 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp
16 	xul.dll 	AutoResolveName::~AutoResolveName() 	js/xpconnect/src/xpcprivate.h
17 	xul.dll 	XPCNativeSet::FindMember(jsid, XPCNativeMember**, XPCNativeInterface**, XPCNativeSet*, bool*) 	js/xpconnect/src/XPCInlines.h
18 	xul.dll 	XPC_WN_NoHelper_Resolve 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp
19 	xul.dll 	js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) 	js/src/vm/NativeObject.cpp
20 	xul.dll 	GetPropertyOperation 	js/src/vm/Interpreter.cpp
21 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp

At least three reports mention printing so maybe that's a lead?
bp-4301ebc4-c408-4ce1-a1e5-b3ae42160420
bp-a3ee26dc-e40e-4caf-a89b-0e18e2160420
bp-d39f053c-0b9a-4212-bbfe-837a82160424
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #1)
> This is currently the #6 crash signature in Thunderbird 38.7.2 accounting
> for 1.12% overall. This is not exclusively a Thunderbird crash but volume
> seems to be much worse in Thunderbird 38.* than either Thunderbird 45.*,
> Firefox, or Fennec.
> >     Firefox 45.0.2:  140 crashes [  2.2 crashes per 1M users]
> >      Fennec 45.0.2:   19 crashes [  3.5 crashes per 1M users]
> > Thunderbird 38.7.2: 1343 crashes [420.8 crashes per 1M users]
> >   Thunderbird 45.0:    4 crashes [  7.8 crashes per 1M users]

Anthony, thanks for looking at the Thunderbird side.

I believe this signature is no longer relevant to Thunderbird 45. All 4 of those crashes are startup, and have different signatures than the THunderbird "printing" crashes.  Either the crash is gone for Thunderbird or the signature changed (but I find not one TB45 crash so far whose comments mentions printing).  

Similarly, the rate for Thunderbird printing bug 1063723 has changed in 45, but not entirely gone.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #3)
> (In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #1)
> > This is currently the #6 crash signature in Thunderbird 38.7.2 accounting
> > for 1.12% overall. This is not exclusively a Thunderbird crash but volume
> > seems to be much worse in Thunderbird 38.* than either Thunderbird 45.*,
> > Firefox, or Fennec.
> > >     Firefox 45.0.2:  140 crashes [  2.2 crashes per 1M users]
> > >      Fennec 45.0.2:   19 crashes [  3.5 crashes per 1M users]
> > > Thunderbird 38.7.2: 1343 crashes [420.8 crashes per 1M users]
> > >   Thunderbird 45.0:    4 crashes [  7.8 crashes per 1M users]
> 
> Anthony, thanks for looking at the Thunderbird side.
> 
> I believe this signature is no longer relevant to Thunderbird 45.

Are we migrating users over to Thunderbird 45 at this point, ie. is Thundbird 38 EOL? If so I vote we close this bug as WONTFIX for Thunderbird 38 and WORKSFORME for Thunderbird 45.
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #4)
> Are we migrating users over to Thunderbird 45 at this point, ie. is
> Thundbird 38 EOL? 

Yes

> If so I vote we close this bug as WONTFIX for Thunderbird
> 38 and WORKSFORME for Thunderbird 45.

Sure. I was going to wait for more data in case the signature had morphed. But realistically I have no idea when I'll get back to this.  Closing per your reasonable suggestion.

And hopefully not adding confusion ... this started as a clone of *Thunderbird crash* bug 1222487. Why a clone was made is unclear to me. But it seems proper to  close 1222487 the same way, so I am doing so.
Status: NEW → RESOLVED
Closed: 8 years ago
status-thunderbird_esr38: affected → wontfix
tracking-thunderbird_esr38: ? → ---
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.