Closed Bug 261543 Opened 20 years ago Closed 18 years ago

Crash with inaccessible fonts files, XF86

Categories

(Core :: Widget: Gtk, defect)

1.8 Branch
x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 183729

People

(Reporter: bartvb, Unassigned)

References

Details

(Keywords: crash)

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.
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.
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 ;)
Summary: Crash when firefox tries to display it's startpage. → Crash with inaccessible TrueType files, XF86
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.
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.
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.
Those talkback IDs are no longer available. Can anyone submit new ones?
*** Bug 263742 has been marked as a duplicate of this bug. ***
(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.
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?
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.
Summary: Crash with inaccessible TrueType files, XF86 → Crash with inaccessible fonts files, XF86
Whiteboard: DUPEME
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
Assignee: bross2 → nobody
Component: General → Widget: Gtk
Keywords: crash
Product: Firefox → Core
QA Contact: general → gtk
Version: unspecified → 1.8 Branch
Can you still reproduce this? This may be a dupe of Bug 183729 which was fixed for Firefox 2.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.