Closed
Bug 434046
Opened 16 years ago
Closed 16 years ago
Crashes on Startup - gfxWindowsFontGroup Signature - Top Crash
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9
People
(Reporter: jlester, Assigned: karlt)
References
Details
(Keywords: crash)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Build Identifier: ftp://ftp.mozilla.org/pub/firefox/nightly/2008/05/2008-05-12-06-firefox3.0rc1 Firefox 3 Beta 5 immediately crashes on startup. I have also tried the latest nightly builds with the same issue. A clean install of Firefox with a new profile still has the problem. I also tried the portable version of FF3b5 with the same issue. This is on a new Vista installation. Firefox worked fine initially, but stopped after the installation of several other programs. I reverted back to Firefox 2 which does not have the problem. I have also uninstalled other programs trying to narrow down at what point it stopped working, but have been unsuccessful. Reproducible: Always Steps to Reproduce: 1. Launch any Firefox 3 build on this particular computer. Actual Results: Immediate crash after the Firefox GUI loads. Choosing restart crashes immediately again. Expected Results: Should have loaded properly. This is currently one of the top crashes. Here are a couple of my reports: http://crash-stats.mozilla.com/report/index/01770763-22bb-11dd-911f-001a4bd46e84?date=2008-05-15-20 http://crash-stats.mozilla.com/report/index/1c8994c5-233e-11dd-bd2f-001cc4e2bf68?date=2008-05-16-11 Signature: gfxWindowsFontGroup::gfxWindowsFontGroup(nsAString_internal const&, gfxFontStyle const*) Crash Reason: EXCEPTION_ACCESS_VIOLATION Crash Address: 0x16 Top Crash: http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b5&range_value=2&signature=gfxWindowsFontGroup%3A%3AgfxWindowsFontGroup%28nsAString_internal+const%26%2C+gfxFontStyle+const%2A%29 I will be glad to help narrow down the problem if someone would give me some thigns to try.
Updated•16 years ago
|
Component: Startup and Profile System → GFX: Thebes
Keywords: crash
Product: Firefox → Core
QA Contact: startup → thebes
gfxWindowsPlatform::FindFontEntry is allowed to return nsnull, but there doesn't seem to be any checks for that. <http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp&mark=793,809,844&rev=1.206#793>
Comment 2•16 years ago
|
||
the ForEachFont() code should always create an array of names that will succeed when calling FindFontEntry -- if we made this code a bit more platform specific ForEachFont would do the FontEntry resolution itself.
Reporter | ||
Comment 3•16 years ago
|
||
I found the application that causes this to happen and can easily duplicate it now. The Novell iFolder v2.1.8 client installs something that causes the problem. Uninstalling it does not fix the issue, I had to do a System Restore in order to get my system back to the point that FF 3 would run again. Installing the iFolder client again causes the problem to reoccur on reboot. The client does not have to be configured, just the act of installing it causes the problem.
dir /s/b c:\windows\fonts > \ifolder-fonts.txt uninstall ifolder dir /s/b c:\windows\fonts > \normal-fonts.txt compare. when you find the fonts, get as much information as you can about them :) if your path isn't c:\windows\fonts please adjust as necessary :) if that doesn't work, there are some registry keys that relate to fonts. you can use regmon or filemon or procmon from sysinternals.com to find the other spots. a long from one of them for "notepad" opening the font picker dialog should work nicely.
(In reply to comment #2) > the ForEachFont() code should always create an array of names that will succeed > when calling FindFontEntry -- if we made this code a bit more platform specific > ForEachFont would do the FontEntry resolution itself. > That only covers two of the three locations where the result from FindFontEntry() entry is being appended to the list. Is there a guarantee that the third addition would always succeed? <http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp&mark=843,844&rev=1.206#843>
We should never fail to find the DEFAULT_GUI_FONT. I can't find any font related stuff in ifolder 3.2.5347.1. Not sure if 2.1.8 can be downloaded anywhere.
Assignee | ||
Comment 7•16 years ago
|
||
(In reply to comment #6) > We should never fail to find the DEFAULT_GUI_FONT. The font entry might have a different name though (bug 418381 comment 15).
Comment 8•16 years ago
|
||
karlt: you're probably right. we probably need to resolve the name after we pull it out before doing the lookup.
Assignee | ||
Comment 9•16 years ago
|
||
(In reply to comment #8) > we probably need to resolve the name after we > pull it out before doing the lookup. There is a build using attachment 322627 [details] [diff] [review], which does that, here: https://build.mozilla.org/tryserver-builds/2008-05-27_04:56-ktomlinson@mozilla.com-default-gui-font-1.1/ Attachment 322628 [details] [diff] tries a bit harder: https://build.mozilla.org/tryserver-builds/2008-05-27_04:56-ktomlinson@mozilla.com-message-font-1.1/ Jason, would you be able to try these builds, please?
Reporter | ||
Comment 10•16 years ago
|
||
(In reply to comment #4) > dir /s/b c:\windows\fonts > \ifolder-fonts.txt > uninstall ifolder > dir /s/b c:\windows\fonts > \normal-fonts.txt > > compare. when you find the fonts, get as much information as you can about them > :) > > if your path isn't c:\windows\fonts please adjust as necessary :) > > if that doesn't work, there are some registry keys that relate to fonts. you > can use regmon or filemon or procmon from sysinternals.com to find the other > spots. a long from one of them for "notepad" opening the font picker dialog > should work nicely. > There were no changes to c:\windows\fonts, that was the first thing I checked. I even uninstalled all non-Windows system fonts with the same issue. Jason
Reporter | ||
Comment 11•16 years ago
|
||
(In reply to comment #9) > (In reply to comment #8) > > we probably need to resolve the name after we > > pull it out before doing the lookup. > > There is a build using attachment 322627 [details] [diff] [review], which does that, here: > > https://build.mozilla.org/tryserver-builds/2008-05-27_04:56-ktomlinson@mozilla.com-default-gui-font-1.1/ > > Attachment 322628 [details] [diff] tries a bit harder: > > https://build.mozilla.org/tryserver-builds/2008-05-27_04:56-ktomlinson@mozilla.com-message-font-1.1/ > > Jason, would you be able to try these builds, please? > The default-gui build #322627 caused a Windows exception crash (the Crash Reporter did not catch it first, so there is no crash report.) The message-font build #322628 seems to have fixed the problem though. Jason
Assignee | ||
Comment 12•16 years ago
|
||
Thank you, Jason. Let us know if you see any problems with the message-font build.
Assignee | ||
Comment 13•16 years ago
|
||
A similar fix using message font on bug 434046 was checked in just in time for RC2.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Assignee | ||
Comment 14•16 years ago
|
||
The nightly build here is essentially code-complete for RC2: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-05-29-01-mozilla1.9.0/ Jason, can I ask you check this to ensure that the final version of the patch fixed the problem, and reply to bug 434401 comment 41, please?
You need to log in
before you can comment on or make changes to this bug.
Description
•