They are new crash signatures and are #1 top crasher in today's build. It's probably related to bug 705154 on Mac OS X. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c8147998124&tochange=de483d897af4 Signature chromehang | NtGdiGetFontData UUID 1b493796-1ea3-4f31-8f2d-1d9982111124 Date Processed 2011-11-24 23:44:33.998314 Uptime 92 Last Crash 1.6 days before submission Install Age 1.5 minutes since version was first installed. Install Time 2011-11-25 07:42:46 Product Firefox Version 11.0a1 Build ID 20111124031031 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture amd64 Build Architecture Info family 6 model 42 stepping 7 Crash Reason EXCEPTION_BREAKPOINT Crash Address 0x7fef16a1ae3 App Notes AdapterVendorID: 1002, AdapterDeviceID: 6760, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.823.0.0 Has dual GPUs. GPU #2: AdapterVendorID2: 8086, AdapterDeviceID2: 0116, AdapterSubsysID2: 00000000, AdapterDriverVersion2: 8.823.0.0D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ xpcom_runtime_abort(###!!! ABORT: HangMonitor triggered: file e:/builds/moz2_slave/m-cen-w64-ntly/build/xpcom/threads/HangMonitor.cpp, line 111) Processor Notes EMCheckCompatibility True Frame Module Signature [Expand] Source 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 msvcr90.dll get_fpsr 2 xul.dll NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:345 3 mozutils.dll arena_malloc_large memory/jemalloc/jemalloc.c:4075 4 mozutils.dll idalloc memory/jemalloc/jemalloc.c:4560 5 mozutils.dll choose_arena memory/jemalloc/jemalloc.c:2891 6 mozutils.dll choose_arena memory/jemalloc/jemalloc.c:2891 7 mozutils.dll je_realloc memory/jemalloc/jemalloc.c:6449 8 xul.dll nsACString_internal::MutatePrep xpcom/string/src/nsTSubstring.cpp:135 9 xul.dll nsCSubstringTuple::WriteTo xpcom/string/src/nsTSubstringTuple.cpp:79 10 xul.dll nsACString_internal::ReplacePrepInternal xpcom/string/src/nsTSubstring.cpp:198 11 xul.dll nsCSubstringTuple::WriteTo xpcom/string/src/nsTSubstringTuple.cpp:72 12 xul.dll CrashReporter::EnumerateEntries toolkit/crashreporter/nsExceptionHandler.cpp:1110 13 mozutils.dll je_malloc memory/jemalloc/jemalloc.c:6230 14 xul.dll CrashReporter::DoFindInReadable toolkit/crashreporter/nsExceptionHandler.cpp:1100 15 mozutils.dll arena_run_dalloc memory/jemalloc/jemalloc.c:3695 16 mozutils.dll arena_dalloc_large memory/jemalloc/jemalloc.c:4517 17 xul.dll xul.dll@0x5bfbf 18 xul.dll nsBaseHashtable<nsCStringHashKey,nsCString,nsCString>::s_EnumReadStub obj-firefox/dist/include/nsBaseHashtable.h:345 19 mozutils.dll je_free memory/jemalloc/jemalloc.c:6504 20 nspr4.dll MD_CURRENT_THREAD nsprpub/pr/src/md/windows/w95thred.c:308 21 nspr4.dll PR_Unlock nsprpub/pr/src/threads/combined/prulock.c:347 22 xul.dll CrashReporter::AnnotateCrashReport toolkit/crashreporter/nsExceptionHandler.cpp:1208 23 xul.dll mozilla::HangMonitor::Crash xpcom/threads/HangMonitor.cpp:111 24 nspr4.dll PR_Unlock nsprpub/pr/src/threads/combined/prulock.c:347 25 xul.dll mozilla::HangMonitor::ThreadMain 26 nspr4.dll MD_CURRENT_THREAD nsprpub/pr/src/md/windows/w95thred.c:308 27 nspr4.dll PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:426 28 msvcr90.dll getptd_noexit 29 nspr4.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:122 30 msvcr90.dll endthreadex 31 msvcr90.dll endthreadex 32 msvcr90.dll get_fpsr 33 kernel32.dll kernel32.dll@0x1652c 34 ntdll.dll RtlUserThreadStart 35 kernel32.dll kernel32.dll@0x992ef 36 kernel32.dll kernel32.dll@0x992ef More reports at: https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox:11.0a1&platform=windows&range_value=1&range_unit=weeks&query_search=signature&query_type=startswith&query=chromehang&build_id=&process_type=any&hang_type=any&do_query=1

This bug as filed is INVALID. Bug 705154 looks like the hang detector malfunctioning on Mac. This bug looks like the hang detector functioning properly on Windows: each of the different crash signatures here needs its own bug and investigation. To note: when the hang detector triggers, it is usually the stack from thread 0 that is interesting, not the stack from the hang detector thread, which is what the crash-stats UI currently shows. Note that the crash signature is properly created from thread 0.