261543 - Crash with inaccessible fonts files, XF86

Status: RESOLVED DUPLICATE of bug 183729

(Core :: Widget: Gtk, defect)

Description

[Bart van Bragt]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Build Identifier: firefox-1.0PR-i686-linux-gtk2+xft

I installed Linux (Debian testing) yesterday, installed Firefox and that worked as 
expected. The fonts where fairly ugly and way to small so I tried installing some 
TrueType fonts. That was a bit more complicated than I thought, I went to bed before I 
got it working properly. 
 
Today I switched on the computer and it was the first time that XFree86 4.3 was 
restarted with the truetype path included. I started firefox, it came up, I saw some 
redirects withing www.mozilla.org and after a few seconds Firefox crashed. This 
seemed to coincide with the moment that Firefox normally displays the rendered page. 

Reproducible: Always
Steps to Reproduce:
1. Do 'something' with truetype fonts 
2. Start firefox with some default page 
3. Crash :\ 
Actual Results:  
 

Expected Results:  
 

Everything was still extremely default, only switched off the bookmarks bar. 
 
Some Talkback crash IDs: 
TB980056W 
TB980066Q 
TB982472K 
 
Thunderbird (0.8) is having the same problems. Seems to crash as soon as it wants to 
display the HTML in the preview pane. 
 
Firefox does work when I start it with: 
 
firefox 'about:blank' 
 
but when I do something like 'Help -> About' it crashes. 
 
Backtrace: 
 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 1085944224 (LWP 5544)] 
0x0841fee6 in nsPRUint32Key::Clone () 
(gdb) bt 
#0  0x0841fee6 in nsPRUint32Key::Clone () 
#1  0x0841ffb9 in nsPRUint32Key::Clone () 
#2  0x08420084 in nsPRUint32Key::Clone () 
#3  0x08414b0a in nsPRUint32Key::Clone () 
#4  0x0840d321 in nsPRUint32Key::Clone () 
#5  0x084c7a87 in nsPRUint32Key::Clone () 
#6  0x084c78ea in nsPRUint32Key::Clone () 
#7  0x0840d9c8 in nsPRUint32Key::Clone () 
#8  0x08418db4 in nsPRUint32Key::Clone () 
#9  0x0841d2b7 in nsPRUint32Key::Clone () 
#10 0x0845bad3 in nsPRUint32Key::Clone () 
#11 0x0845b7e7 in nsPRUint32Key::Clone () 
#12 0x082711e3 in nsReadingIterator<unsigned short>::advance () 
#13 0x0826ea3a in nsReadingIterator<unsigned short>::advance () 
#14 0x082711e3 in nsReadingIterator<unsigned short>::advance () 
#15 0x08277628 in nsReadingIterator<unsigned short>::advance () 
#16 0x0841b646 in nsPRUint32Key::Clone () 
#17 0x0841b47d in nsPRUint32Key::Clone () 
#18 0x082711e3 in nsReadingIterator<unsigned short>::advance () 
#19 0x08273e66 in nsReadingIterator<unsigned short>::advance () 
#20 0x0841ab24 in nsPRUint32Key::Clone () 
#21 0x08418db4 in nsPRUint32Key::Clone () 
#22 0x0843c8d4 in nsPRUint32Key::Clone () 
#23 0x08224c6c in nsReadingIterator<unsigned short>::advance () 
#24 0x0822e103 in nsReadingIterator<unsigned short>::advance () 
#25 0x0822ee45 in nsReadingIterator<unsigned short>::advance () 
#26 0x400f513b in PL_HandleEvent () from /opt/firefox/libxpcom.so 
#27 0x400f508e in PL_ProcessPendingEvents () from /opt/firefox/libxpcom.so 
#28 0x400f66a9 in nsEventQueueImpl::NotifyObservers () from /opt/firefox/libxpcom.so 
#29 0x0820edfc in nsReadingIterator<unsigned short>::advance () 
#30 0x405bff7f in g_vasprintf () from /usr/lib/libglib-2.0.so.0 
#31 0x4059a932 in g_main_depth () from /usr/lib/libglib-2.0.so.0 
#32 0x4059ba28 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 
#33 0x4059bd60 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 
#34 0x4059c3a3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 
#35 0x40292213 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 
#36 0x0820f0ab in nsReadingIterator<unsigned short>::advance () 
#37 0x085ccf23 in nsPRUint32Key::Clone () 
 
 
Alas I have no idea how to fix this, I tried to revert my font changes as much as possible. 
All I did (iirc) was copying my .ttf files to a dir and adding a 'fontpath' line to my X config, 
besides that I removed the "unix/:7100" fontpath (but I don't think that I'm running a 
fontserver). I reverted those changes but Firefox is still crashing. 
 
Oh, I also enabled truetype (freetype) in /opt/firefox/greprefs/all.js  but I disabled that 
again when firefox started crashing. Haven't enabled freetype in thunderbird yet.

Comment 1

[Bart van Bragt]

And the plot thickens...

If I do:

su -m

before I start firefox or thunderbird then everything works perfectly :\ So I
can run Firefox as root which is using exactly the same profile as my normal user.

I also tried deleting ~/.mozilla and then starting it as a normal user and that
didn't work.

Also tried creating a new account, opening an X session and starting Firefox
(with a clean slate) but that also resulted in a crash.

But at least I'm again able to run a decent webbrowser again. It's running as
root but that's not really that much worse than when I was still using Windows :)

Still extremely curious what is causing this. Please tell me if you need more
information from me.

Comment 2

[Bart van Bragt]

Ok, I figured it out ;) It was only working as root because all the TrueType
fonts that I added where only readable by root. *sigh*

As soon as I changed the permissions for the TrueType files everything started
working again.

But this could still be handled better, some error message or reverting to
readable font files would be nice ;)

Comment 3

[mark krischer]

i just had the same problem.  and it took forever to figure out what was causing
it.  there definitely needs to be a cleaner way of handling this than silently
failing with no indication of what went wrong.

Comment 4

[Ciro]

Same problem happened here, from Firefox 0.9 to the nightly build for 29 Nov,
2004, and TBird 7.1.

Really need some error handling here. 

Comment 5

[Paul d'Aoust]

I thought I'd add my own findings... I also added these findings in bug 263742
before I knew about this bug.

I receive the same results with Firefox 0.99 and Firefox 1.0 (Ubuntu 1.0-2
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.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Those talkback IDs are no longer available. Can anyone submit new ones?

Comment 7

[:Gavin Sharp [email: [e-mail]]]

*** Bug 263742 has been marked as a duplicate of this bug. ***

Comment 8

[rjhorn]

(In reply to comment #7)
> *** Bug 263742 has been marked as a duplicate of this bug. ***

I tracked down my specific problem (263742) and it was indeed a font access
issue.  In my case it was one specific font file that was not world readable,
rather than a font directory search problem.

An expected end user behavior for a case like this would be to fall back onto
the user fonts, and to have an indication/warning somewhere that a font access
problem has occurred.  It is especially hard to track down when there is just
one problem font among many good fonts, so an indication of the font that has
the problem is needed.

Comment 9

[Oren Shani]

Same problem happens when the fonts are inacessible for any reason (e.g. when
the files are missing). Is this realy a freetype problem and not FF's?

Comment 10

[Shoshannah Forbes]

Oren- can you please attach your crash reports here?

Anyway, I am adjusting the title, as FF seems to crash not only when TTF fonts
are missing, but also when type1 fonts are missing.

Comment 11

[JohnGH]

This is still happening in Firefox 1.5.0.4

I have added some Windows TTF fonts to my Debian Etch by symlinking them from the Windows partition (because you're not allowed to download Tahoma font - but I already legally have it installed on my PC as part of Windows XP):

lrwxrwxrwx 1 root root 31 Apr 18 18:08 /usr/share/fonts/truetype/msttcorefonts/Tahoma.ttf -> /mnt/c/WINDOWS/Fonts/tahoma.ttf
lrwxrwxrwx 1 root root 10 Apr 18 18:16 /usr/share/fonts/truetype/msttcorefonts/tahoma.ttf -> Tahoma.ttf
lrwxrwxrwx 1 root root 15 Apr 18 18:17 /usr/share/fonts/truetype/msttcorefonts/tahomabd.ttf -> Tahoma_Bold.ttf
lrwxrwxrwx 1 root root 33 Apr 18 18:08 /usr/share/fonts/truetype/msttcorefonts/Tahoma_Bold.ttf -> /mnt/c/WINDOWS/Fonts/tahomabd.ttf
lrwxrwxrwx 1 root root 50 Apr 18 18:22 /var/lib/defoma/gs.d/dirs/fonts/Tahoma.ttf -> /usr/share/fonts/truetype/msttcorefonts/Tahoma.ttf
lrwxrwxrwx 1 root root 55 Apr 18 18:22 /var/lib/defoma/gs.d/dirs/fonts/Tahoma_Bold.ttf -> /usr/share/fonts/truetype/msttcorefonts/Tahoma_Bold.ttf
lrwxrwxrwx 1 root root 50 Apr 18 18:23 /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/Tahoma.ttf -> /usr/share/fonts/truetype/msttcorefonts/Tahoma.ttf
lrwxrwxrwx 1 root root 55 Apr 18 18:23 /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/Tahoma_Bold.ttf -> /usr/share/fonts/truetype/msttcorefonts/Tahoma_Bold.ttf

since changing my C: drive to mount read/write using NTFS fuse I find that it is not mounting on startup from /etc/fstab (I need to look into this)

/dev/hda1       /mnt/c  ntfs-fuse       rw,nosuid,nodev,uid=1000,gid=1000,umask=0007    0 0

but the way I keep reminding myself to mount it is that whenever I try and view a page that needs Tahoma font using Firefox, Firefox will instantly crash due to the dangling symlink:

/usr/share/fonts/truetype/msttcorefonts/Tahoma.ttf -> /mnt/c/WINDOWS/Fonts/tahoma.ttf

If I run firefox with:

        strace firefox

then try and open a page which has Tahoma font in it it crashes immediately and I find this in the end of the strace output:

open("/usr/share/fonts/truetype/msttcorefonts/tahoma.ttf", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/fonts/truetype/msttcorefonts/tahoma.ttf", O_RDONLY) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/home/john/.mozilla/firefox/bhvuxu6e.slt/lock") = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(17378, 17378, SIGSEGV)           = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 17378 detached

Comment 12

[Kevin Brosnan]

Can you still reproduce this? This may be a dupe of Bug 183729 which was fixed for Firefox 2.