Closed Bug 434046 Opened 16 years ago Closed 16 years ago

Crashes on Startup - gfxWindowsFontGroup Signature - Top Crash

Categories

(Core :: Graphics, defect)

x86
Windows Vista
defect
Not set
critical

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.
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>
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.
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.
(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).
karlt: you're probably right.  we probably need to resolve the name after we pull it out before doing the lookup.
(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?
(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
(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
Thank you, Jason.  Let us know if you see any problems with the message-font build.
Assignee: nobody → mozbugz
Status: UNCONFIRMED → NEW
Depends on: 434401
Ever confirmed: true
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
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.