Closed Bug 263742 Opened 20 years ago Closed 20 years ago

Linux font crash for missing/unavail/?? font

Categories

(Firefox :: General, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 261543

People

(Reporter: rjhorn, Assigned: bugzilla)

References

()

Details

(Keywords: stackwanted)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041009 Firefox/0.9.1+

This site has a mouseover to trigger a font change, from verdana to tahoma, and
a color change.  That font change causes a crash.  This crash behavior began
with firefox version 0.9.  If I use the option to always use my fonts, the crash
does not occur.  The page obviously looks different, and the mouseover only
causes the color change.

The bug affects many other pages, but they cause a crash during load/render. 
This page has the mouseover style change that helps isolate it to something
specifically font related.

This may be related to bug 261543.

Firefox shouldn't crash for unavailable fonts.  It should perhaps generate an
error, and then act drop back to user default fonts.  They may look wrong or
different, but it's better than crashing.

Reproducible: Always
Steps to Reproduce:
1. load the page.  (This page requires registration, so set up a dummy account
if necessary.  Go to www.concept2.com and select "personal logbook" to start
that process.)  You will need to log in to the personal logbook get to the
problem page.
2. Mouseover any of the heading fields, e.g. "Challenges"
3.
Actual Results:  
Crashes on mouseover

Expected Results:  
Use alternative user font, perhaps with error message somewhere

I'm using a SuSE 9.1 generic install and haven't done anything special for
fonts.  If there are specific things to check I can provide more info.

There are a smattering of talkbalks for this.  From time to time I try new
releases to see whether this is fixed.
reporter: it'd help if you mentioned the talkbackids
Keywords: stackwanted
(In reply to comment #1)
> reporter: it'd help if you mentioned the talkbackids

Two from today for this new version are:

TB1231810G
TB1226987M
I thought I'd add my own experiences with this same bug: I receive the same
results with Firefox 0.99 and Firefox 1.0 (Ubuntu packages). It appears that, if
a font exists but is unavailable (e.g., inside a directory that is marked rw-
instead of rwx) that's when it'll fail. When rendering a page with fonts that
are simply not on my computer, Firefox will choose alternate fonts gracefully.

Unfortunately I can't find any debugging package for Ubuntu, so I can't give any
TalkBack or coredumps or anything. I do know, however, that Firefox experiences
a segmentation fault at this point (using strace):

open("/var/lib/defoma/fontconfig.d/K/KochiMincho-Regular.ttf", O_RDONLY) = -1
EACCES (Permission denied)
open("/var/lib/defoma/fontconfig.d/K/KochiMincho-Regular.ttf", O_RDONLY) = -1
EACCES (Permission denied)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/home/paul/.mozilla/firefox/default.7y4/lock") = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(6795, 6795, SIGSEGV)             = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

/var/lib/defoma/fontconfig.d/K/KochiMincho-Regular.ttf appears to be a symlink
that points to /usr/share/fonts/truetype/kochi/KochiMincho-Regular.ttf. I
purposefully took off the execute bit off the directory
/usr/share/fonts/truetype/kochi for the purposes of this report.
Those talkback IDs are no longer available.

*** This bug has been marked as a duplicate of 261543 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.