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: 184.108.40.20664 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
bug 662055 is in the regression range.
(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?
(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.
maybe, this is related to bug 699247. t2embed is defined as delay load dll by this fix.
(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.
I didn't revert GetProcAddress calls for readability and less complexity.
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #601236 - Flags: review?(jmathies)
Whiteboard: [startupcrash] → [startupcrash] [autoland-try:try:-b do -p win32 -u all -t none]
Whiteboard: [startupcrash] [autoland-try:try:-b do -p win32 -u all -t none] → [startupcrash] [autoland-try:-b do -p win32 -u all -t none]
Whiteboard: [startupcrash] [autoland-try:-b do -p win32 -u all -t none] → [startupcrash] [autoland-in-queue]
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
Attachment #601236 - Flags: review?(jmathies) → review?(jdaggett)
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.
Attachment #601236 - Flags: review?(jdaggett) → review+
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://firstname.lastname@example.org
Whiteboard: [startupcrash] [autoland-in-queue] → [startupcrash]
I also confirmed that the current nightly crashed with t2embed.dll disabled and the patched build did no longer crash in the same condition.
Target Milestone: --- → mozilla13
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I see one crash in 13.0a1/20120304: bp-44d76c1e-49f2-4aff-8da8-de9a42120305
(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.
Crash Signature: [@ __delayLoadHelper2] → [@ __delayLoadHelper2] [@ __delayLoadHelper2 | xul.dll@0x2fb6d0]
Depends on: 731894
You need to log in before you can comment on or make changes to this bug.