Crashes on Startup - gfxWindowsFontGroup Signature - Top Crash

RESOLVED FIXED in mozilla1.9

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Jason Lester, Assigned: karlt)

Tracking

({crash})

unspecified
mozilla1.9
x86
Windows Vista
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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

Comment 1

10 years ago
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

10 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

10 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.

Comment 4

10 years ago
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.

Comment 5

10 years ago
(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

10 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

10 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

10 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

10 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

10 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

10 years ago
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
(Assignee)

Comment 13

10 years ago
A similar fix using message font on bug 434046 was checked in just in time for RC2.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
(Assignee)

Comment 14

10 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.