User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718 Build Identifier: any Linux CVS build over the last two or so months (at least, possibly longer) Upon loading www.zeit.de (before anything is displayed in the browser window) Mozilla crashes without any output to the console. This only happens in a build where Xft is enabled - I did a build with disabled Xft, and it didn't crash. Optimization flags don't have an impact: I compiled both with and without optimization, and both crashed, given that Xft was enabled. Reproducible: Always Steps to Reproduce: 1. Build an Xft-enabled Mozilla 2. Go to www.zeit.de (URL-bar, bookmark, whatever) 3. Mozilla crashes Actual Results: Mozilla starts downloading data from the net, and then crashes before anything is displayed in the window; no output to the console. Expected Results: It believe it shouldn't crash :-) RedHat 9, stock kernel 2.4.21 from www.kernel.org Athlon 2,4GHz freetype 2.1.3 XFree 4.3.0 NVIDIA GeForce2 MX with NVIDIA driver version 4363 www.zeit.de is the only page where I can reliably get a crash when Xft is enabled - somehow, this seems to be related to something on that page. I have tried, without success: o moved away my ~/.mozilla, and let Mozilla create a completely new account o moved away all plugins o did a clobber build from newly downloaded Source, after CVS update I cannot pin down the time when the problem started, since I don't frequent the site regularly - however, I'm absolutely sure that there was a time when Mozilla didn't crash there. I have used Xft since it was available, so I strongly believe that either something has changed on their site to trigger this bug, or this problem appeared at some point in time. Over the last two months or so, I have regularly built from CVS, and all builds had this problem. I posted this on the Mozillazine Mozilla-Bugs forum, and on the mozilla.unix newsgroup - however, I didn't get the feedback I hoped for. 'Die Zeit' is the most important weekly quality newspaper in Germany. If Xft is more widely adopted, this problem will become much more visible in the Linux community. E.g., RedHat supplies Xft-enabled Mozilla builds, and they crash as well. (BTW, my hat is off to Peter Buhr, the webmaster of www.zeit.de: after I posted on mozillazine and the newsgroup and didn't get any usable feedback, I didn't follow through with further debugging. It seems that Peter found my posting, and on his own initiative contacted me with questions on how to reproduce the problem, which in turn prompted me to do further debugging and to finally file this bug. Peter, thanks for your efforts!)
Assignee: font → blizzard
Component: Layout: Fonts and Text → GFX: Gtk
do you have any ttf fonts that are not world-readable? see bug 183729 can you grab a stacktrace via gdb?
Depends on: 198955
Re: Comment #2: Andrew, you were very close - close enough for me to find the cause of the problem. In my case, it wasn't wrong permissions, but rather dangling links to fonts that didn't exist anymore. It seems that at some point in time I though it would be a good idea to link TTF fonts from my windows partition into one of the directories mentioned in the fontconfig configuration file. For one reason or another (probably a Windows update) the content of the Windows font directory changed, and left some links dangling. Probably, www.zeit.de tries to use a font that happens to be one of those links, and crashes with something similar to bug 183729. As soon as I removed all of the broken links, the page loaded perfectly fine. What should I do with this bug? Make it a duplicate of bug 183729, since the mechanism for the crash is the ungraceful handling of an unreadable Xft font?
> What should I do with this bug? Make it a duplicate of bug 183729...? sounds good. I think someone else reported a similar problem (busted links) in that bug anyway. *** This bug has been marked as a duplicate of 183729 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
No longer depends on: 198955
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.