730550 - Crash in gfxUserFontSet::OnLoadComplete @ __delayLoadHelper2

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

It's a new crash signature that first appeared in 13.0a1/20120224 with that stack.
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5e756e59a794&tochange=cd120efbe4c6

Signature 	__delayLoadHelper2 More Reports Search
UUID	88d7380e-2a79-4a01-9c6c-d66f82120224
Date Processed	2012-02-24 22:34:33
Uptime	3911
Install Age	4.0 hours since version was first installed.
Install Time	2012-02-24 18:36:39
Product	Firefox
Version	13.0a1
Build ID	20120224031039
Release Channel	nightly
OS	Windows NT
OS Version	5.1.2600 Service Pack 3, v.6165
Build Architecture	x86
Build Architecture Info	GenuineIntel family 15 model 3 stepping 4
Crash Reason	0xc06d007e / 0x00000000
Crash Address	0x7c812aeb
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2582, AdapterSubsysID: 00000000, AdapterDriverVersion: 6.14.10.4764
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers-
WebGL? EGL? EGL+
GL Context? GL Context+
WebGL+
EMCheckCompatibility	True	
Total Virtual Memory	2147352576
Available Virtual Memory	1720262656
System Memory Use Percentage	49
Available Page File	1720418304
Available Physical Memory	1500168192

Frame 	Module 	Signature [Expand] 	Source
0 	kernel32.dll 	RaiseException 	
1 	xul.dll 	__delayLoadHelper2 	delayhlp.cpp:325
2 	xul.dll 	xul.dll@0x2fb6d0 	
3 	xul.dll 	gfxUserFontSet::OnLoadComplete 	gfx/thebes/gfxUserFontSet.cpp:505
4 	xul.dll 	nsDocLoader::doStopDocumentLoad 	uriloader/base/nsDocLoader.cpp:974
5 	ntdll.dll 	NtReleaseSemaphore 	
6 	nspr4.dll 	md_UnlockAndPostNotifies 	nsprpub/pr/src/md/windows/w95cv.c:184
7 	nspr4.dll 	md_UnlockAndPostNotifies 	nsprpub/pr/src/md/windows/w95cv.c:193
8 	ntdll.dll 	RtlpFreeToHeapLookaside 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=__delayLoadHelper2

Comment 1

[Scoobidiver (away)]

bug 662055 is in the regression range.

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Scoobidiver from comment #1)
> bug 662055 is in the regression range.

It is, but OTOH it seems highly unlikely to have any effect on this; I think we need to look elsewhere, possibly earlier.

FWIW, I notice that many of the crash reports for __delayLoadHelper2 are not actually this stack, but other unrelated places. Can we do a query that only shows the ones with gfxUserFontSet::OnLoadComplete on the stack?

Comment 3

[Scoobidiver (away)]

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> FWIW, I notice that many of the crash reports for __delayLoadHelper2 are not
> actually this stack
Startup crashes with this stack started in 13.0a1/20120224 (checked manually). The regression range is given in comment 0.

> Can we do a query that only shows the ones with gfxUserFontSet::OnLoadComplete
> on the stack?
You can't do that with the current version of Socorro.

Comment 4

[Makoto Kato [:m_kato]]

maybe, this is related to bug 699247.  t2embed is defined as delay load dll by this fix.

Comment 5

[John Daggett (:jtd)]

(In reply to Makoto Kato from comment #4)
> maybe, this is related to bug 699247.  t2embed is defined as delay load dll
> by this fix.

I can definitely imagine patterns where t2embed will *not* be available.  This library has historically been a source of multiple security alerts/fixes and one of the recommended workarounds was to deny access to the library:

http://technet.microsoft.com/en-us/security/bulletin/ms11-087

This is a 2011 issue but other issues have occurred in the past.

The solution would be to undo the parts of the patch for bug 699247 that removed the dynamic loading of t2embed functions.

Comment 6

[Masatoshi Kimura [:emk]]

Attachment: Make sure the t2embed library is available before using

I didn't revert GetProcAddress calls for readability and less complexity.

Comment 7

[Mozilla RelEng Bot]

Autoland Patchset:
	Patches: 601236
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/pushloghtml?changeset=99efe03dcd47
Try run started, revision 99efe03dcd47. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=99efe03dcd47

Comment 8

[John Daggett (:jtd)]

Comment on attachment 601236 [details] [diff] [review]
Make sure the t2embed library is available before using

Looks like this will work.  Please confirm for the case where deny access has been set, using the workaround instructions in the security bulletin in comment 5.

Comment 9

[Mozilla RelEng Bot]

Try run for 99efe03dcd47 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=99efe03dcd47
Results (out of 49 total builds):
    success: 40
    warnings: 5
    failure: 4
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-99efe03dcd47

Comment 10

[Masatoshi Kimura [:emk]]

I also confirmed that the current nightly crashed with t2embed.dll disabled and the patched build did no longer crash in the same condition.

Comment 11

[Dão Gottwald [::dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/33b47f176473

Comment 13

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/33b47f176473

Comment 14

[Scoobidiver (away)]

I see one crash in 13.0a1/20120304: bp-44d76c1e-49f2-4aff-8da8-de9a42120305

Comment 15

[Makoto Kato [:m_kato]]

(In reply to Scoobidiver from comment #14)
> I see one crash in 13.0a1/20120304: bp-44d76c1e-49f2-4aff-8da8-de9a42120305

Exception code is different.  0C06D007Fh means that GetProcAddress returns NULL.