459711 - crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page because of OpenOffice.org's corrupt font (Deja Vu Sans Extra Light)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Oscar van Vliet]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en; rv:1.9.0.4pre) Gecko/2008092700 Camino/2.0a1pre (like Firefox/3.0.4pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en; rv:1.9.0.4pre) Gecko/2008092700 Camino/2.0a1pre (like Firefox/3.0.4pre)

I have had two crashes in two days of Camino 2a1pre. In both cases, I have around 10 tabs open, and had been surfing for at least half a day without quitting. I think that in both cases I was viewing either anandtech.com or dailytech.com. I clicked on my Wikipedia main page link in the bookmark bar and Camino crashed after what seemed to be a second of heavy thinking.

Reproducible: Sometimes

Steps to Reproduce:
1. Have several tabs open and browse for a while
2. Read a story on anandtech.com or dailytech.com (I think)
3. Click on Wikipedia in the bookmarks bar.
Actual Results:  
Camino crashed. See TB50339254E and TB 50357553H

Expected Results:  
I expected Camino to display Wikipedia and continue.

Comment 1

[Oscar van Vliet]

Attachment: Console.log excerpt

Comment 2

[Oscar van Vliet]

Attachment: Crashreporter.log excerpt

Comment 3

[Oscar van Vliet]

Between the crash logs and the talkback IDs, I hope you can find it.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Talkback didn't catch anything useful, but your crash logs and console info are good :)

This looks a lot like the crash in bug 459531 (and a little like the one in bug 401443).  John, any chance these are all the same thing (and/or related)?  Why are we seeing QuickDraw in there at all?

Comment 5

[Oscar van Vliet]

I should have two more crashlogs for you if you need them :/. Including one with yesterday's nightly. TB50396341Q. Let me know if you want more logs.

It just crashes somewhere, I think on en.wikipedia.org or meta.wikipedia.org.
Good luck on this, it is starting to get pretty frequent.

Comment 6

[Chris Lawson (gone)]

Oscar, what are your font settings? I can't seem to reproduce this myself.

Comment 7

[philippe (part-time)]

Also: are you logged in into Wikipedia ? And: do you have fonts installed for some of the less common languages (South-Asian one in particular, as some of them are not covered by default on OS X ?)

I can't repro the issue either (and I'm not logged in).

Comment 8

[Oscar van Vliet]

Attachment: user preferences

preferences, including two font prefs.

Comment 9

[Oscar van Vliet]

I am logged in to Wikipedia (username: ovvldc), though Camino crashed again when I first tried to check. I attached a prefs.js file. I do have various uncommon fonts installed, but not South-Asian ones, and I would be happy to post a list.

It may be linked to my iBook G4/Mac OS X 10.4.11 going to sleep and waking up, because I do not get the crashes immediately when I restart Camino. It takes some surfing to prime this bug. If you need a history, feel free to say so.

Comment 10

[Oscar van Vliet]

Another bunch of crashes. I don't think it has much to do with sleeping. Also with the latest nightly, see TB50491961 and crashlogs which I will attach shortly.

Comment 11

[Oscar van Vliet]

Attachment: system log excerpt 2

Comment 12

[Oscar van Vliet]

Attachment: console log excerpt 2

Comment 13

[Oscar van Vliet]

Attachment: Camino crash log excerpt 2

Comment 14

[Oscar van Vliet]

FYI, the crashes are always when Camino says it is retrieving from meta.wikimedia.org in the status bar.

I know they can't be reproduced reliably, but they crop up faster and faster on my end. I have started to avoid Wikipedia. However, I have not had any crashes browsing wikia.com.

Comment 15

[Oscar van Vliet]

Attachment: history.dat excerpt

I added a history.log excerpt. I stripped away everything from before the latest crash.

Comment 16

[philippe (part-time)]

I meant to ask this before: are all your custom/third-party/uncommon fonts installed in ~/Library/fonts ?
If so, this might be worth a try:
1. Create a new OS X user (System Preferences > Accounts)
2. Log in as that new user
3. try surfing around a bit, your regular pattern/sites/...
Can you reproduce the crash in that case ?

(if the crash is related some font, it probably won't happen with another user, as that user won't see the font in the original ~/Library/fonts)

Comment 17

[Oscar van Vliet]

No they're not. They are all in /library/fonts, useable by all users. I can post a listing of all the fonts there, if you want. They are mostly MS Office 2003, PC-holdover old WordPerfect fonts and one two downloaded extras.

Also, I have noticed the problems occur mostly when there is a lot of network activity going on in the background. Maybe the code chokes on a bit that wasn't completely downloaded: trying to use it when info on a glyph is incomplete or something..

Finally, I have had Yahoo! webmail and these four pages open in other tabs on every crash:
http://gids.omroep.nl/
http://en.wikipedia.org/wiki/Society_of_the_Song_Dynasty
http://en.wikipedia.org/wiki/Technology_of_the_Song_Dynasty
http://www.nature.com/nrn/journal/vaop/ncurrent/full/nrn2473.html

Comment 18

[Oscar van Vliet]

Attachment: sample taken from Camino hanging *after* a crash

Funny thing happened: I opened Wikipedia in the full expectancy that it would crash. It did, but when I told OSX to close it, it hung and stayed on. So I opened activity monitor and took a sample.

The sample may not be related to this bug, but since it happened on loading Wikipedia, I thought I'd give it a go.

Comment 19

[John Daggett (:jtd)]

Have you tried clearing your font caches?  Assuming you're on 10.4, you can use the utility below:

http://homepage.mac.com/mdouma46/fontfinagler/

> This looks a lot like the crash in bug 459531 (and a little like the one
> in bug 401443).  John, any chance these are all the same thing (and/or 
> related)?  Why are we seeing QuickDraw in there at all?

Yeah, my guess is that this is really the same problem as those other two bugs.  The crash occurs in ATSUI layout code which must be packaged together with QD.

Oscar, can you reproduce this on your system relatively regularly? If this happens fairly easily on your machine, I can probably set up a build with special logging so we can at least figure out the font/character/glyph combination that produces this bug.

Comment 20

[Oscar van Vliet]

John, I can reproduce this bug every few hours recently, and I would be happy to try a build with logging. I will try fontfinagler now, and let you know if I no longer see crashes after that.

Comment 21

[Oscar van Vliet]

So far, the crash hasn't appeared yet since I cleaned the font cache. Fingers crossed!

Comment 22

[Oscar van Vliet]

OK, I had sneaking suspicion about what might be interfering here. After running crash-free for a few days, I reinstalled a NeoOffice 3.0 pre-pre-alpha build that I had looked at for a bit. And the next morning, Camino crashed again.

The crash was a little further along, this time it seemed to come on upload.wikimedia.org, and the page did appear after reopening Camino (though closing still didn't work). I am using the 2.0a release candidate build that Smokey announced.

I filed bug 3273 with NeoOffice, see https://bugzilla.neooffice.org/bug.php?op=show&bugid=3273

Please let me know if you want me to send the font cache files that Font Finagler can clean up for debugging. I can also send the latest crash logs.

Comment 23

[Oscar van Vliet]

Patrick Luby, developer of NeoOffice, suggested another test. I have done as he suggested, and I will report back in a few days.

Comment 24

[Oscar van Vliet]

I have removed two fonts, that originated from OOo-build, and now the crashing stopped. Patrick Luby said he would remove them if this is the case. The fonts in question are Deja Vu (DejaVu*.ttf) and Liberation (Liberation*.ttf).

I am closing this bug as RESOLVED INVALID because the cause was removed and not inside Camino. On the other hand, it might pay to make the font code more tolerant for malformed fonts (if at all possible) because there will be users with bad fonts out there.

Comment 25

[timeless]

http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=18623
http://discussions.apple.com/message.jspa?messageID=8252601

would someone please file a bug in radar?

Comment 26

[philippe (part-time)]

Oscar,
Which version of those fonts do you have ? I have DejaVu (2.26 and before 2.15) installed without any problem. I need to check the Liberation one though.

Comment 27

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*Presumably* the problematic font is DejaVuSansExtraLight.ttf, v2.21, as Font Book on 10.5 reports that it fails validation with a serious error in "'kern' table structure and contents".

I haven't yet crashed as a result of installing the build of NeoOffice with these fonts, but I haven't done much browsing yet, which was required for Oscar (I'm also on 10.5.5 Intel and he's 10.4.11 PPC).

John, what do we want to do next here, if anything?

(In reply to comment #25)
> http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=18623
> http://discussions.apple.com/message.jspa?messageID=8252601
> 
> would someone please file a bug in radar?

Those appear unrelated to this bug.

Comment 28

[philippe (part-time)]

(In reply to comment #27)
> *Presumably* the problematic font is DejaVuSansExtraLight.ttf, v2.21, as Font
> Book on 10.5 reports that it fails validation with a serious error in "'kern'
> table structure and contents".

v 2.26 suffers from the same issue.
v 2.15 validates just fine (that is the set I was using until recently).

I suspect that those DejaVu fonts are used as a fallback for one of the (S-Asian ?) languages, where Oscar does not have coverage via other fonts.

Comment 29

[John Daggett (:jtd)]

(In reply to comment #27)
> *Presumably* the problematic font is DejaVuSansExtraLight.ttf, v2.21, as Font
> Book on 10.5 reports that it fails validation with a serious error in "'kern'
> table structure and contents".

Smokey, can you reproduce this regularly?  Or just every now and then?  It would be great if we could get a reproducible testcase for this.  If we can't get a reproducible testcase, I can put together a logging build that logs all calls to GetCharWidth along with font info.  We can then use those logs to try to put together a testcase that sparks the crash and feed it to Apple.

Comment 30

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I hadn't seen this until I finished dinner tonight; when I returned, Camino had randomly crashed.  Aside from Tinderbox reloading, I'm not sure what was magically loading on its own.  My guess is that the crash will be pretty random for me.

Since the try-server can't build Camino, if you want to post a patch for the logging, I'll be happy to make a build for Oscar and me to use.

Comment 31

[Oscar van Vliet]

I'll try a debug build, no problem.

Comment 32

[John Daggett (:jtd)]

Attachment: patch, enable logging of text runs and InitMetrics

This patch enables:

* dumping of text run info, including font matching
* specifically logs all calls to InitMetrics, where this crash occurs

To use, build with the patch and run from the command-line after entering:

  export NSPR_LOG_MODULES=atsuiTextRun:5
  export NSPR_LOG_FILE=atsuiTextRun.out

Run until the crash occurs and attach the atsuiTextRun.out file.  I'm going to run a try server build now, as this is not Camino-specific.

Comment 33

[John Daggett (:jtd)]

A build using latest trunk code (3.2a1pre) with logging enabled for the routine where the crash occurs can be found here:

  https://build.mozilla.org/tryserver-builds/2008-12-04_23:[e-mail]-initmetricslogginghg2/
  
To use this, download the Mac build (.dmg) and copy the application called Minefield.app to your desktop

1. Download Mac build (.dmg)
2. Open the archive and copy the application, Minefield.app to your desktop
3. Quit Firefox
4. Open Terminal
5. Run Firefox using the following commands:

  cd Desktop/Minefield.app/Contents/MacOS/
  export NSPR_LOG_MODULES=atsuiTextRun:5
  export NSPR_LOG_FILE=atsuiTextRun.out
  ./firefox

6. Run until Firefox crashes

The last line in the output file, atsuiTextRun.out, will indicate the font causing the problem.

Comment 34

[Oscar van Vliet]

****, I've deleted the offending fonts by now so running the Debug Build would be pretty useless.

Smokey, do you still have the DejaVu and Liberation fonts somewhere? If not I will ask Patrick. I presume he still has them in the OOo-build tree somewhere..

Comment 35

[John Daggett (:jtd)]

I was able to find a copy of the bad fonts in the Open Office 3.0 distro.  

1. Download Open Office 3.0 Mac to the Desktop
2. Open Terminal
3. Enter these commands, substituting the exact appname for [OpenOffice.app]

  cd ~/Desktop
  find [OpenOffice.app] -name "*.ttf" -print

You should see a set of fonts listed.

Comment 36

[philippe (part-time)]

(In reply to comment #34)
> Crap, I've deleted the offending fonts by now so running the Debug Build would
> be pretty useless.
> 
> Smokey, do you still have the DejaVu and Liberation fonts somewhere? If not I
> will ask Patrick. I presume he still has them in the OOo-build tree somewhere..

I don't think they ship a custom version of those fonts, so you should be able to repro the issues with the release version of DejaVu:
http://sourceforge.net/projects/dejavu/
(v 2.27 still has the bad table for DejaVuSans-ExtraLight, according to FontBook)

Comment 37

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yeah, I saved an archive at one point, just to be safe.  As I said in comment 27, presumably this is DejaVuSansExtraLight.ttf, but the whole folder is there.

Original contents of Neo3's NeoOffice.app/Contents/basis-link/share/fonts/truetype: http://www.ardisson.org/smokey/moz/neooffice3_original_fonts.zip

If Oscar can't trigger a crash before this weekend (ha!), I should have some time then to try then.

Comment 38

[Oscar van Vliet]

I have the version 2.2.1 of the DejaVuSansExtraLight from Smokey, but it doesn't report any errors in my 10.4 fontbook.

I am writing this from the Minefield Firefox, but the crash hasn't triggered yet :(. Then again, I've only been using it for half an hour or so. Will let you know how things develop.

Comment 39

[Oscar van Vliet]

I've now spent a day and a half running the same instance and it has stubbornly refused to crash. This always happens when I deliberately go for recording samples and such :/.

Maybe there is a difference between Firefox and Camino that could be saving your Minefield build from this crash? Or is it another ghost in the Cocoa Widgets perhaps? I'll stop the Minefield build for now and use yesterday's Camino nightly to see if anything changed there.. 

The only terminal output I have seen so far is Adblock Plus: Failed to read filters from file <$Profile_Folder>/adblockplus/patterns.ini: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileInputStream.init]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://adblockplus/content/filterStorage.js :: anonymous :: line 355"  data: no], which seems entirely unrelated...

Comment 40

[Oscar van Vliet]

I've been running Camino 2.0 nightlies for a few days now, and it refuses to crash as well. The offending versions of the DejaVu and Liberation fonts are still in my personal fonts folder. 

For me, this bug is in limbo somewhere: I wouldn't know of anything that fixed it, but I can no longer reproduce it..

Comment 41

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

So, I reinstalled the fonts (put them back in NeoOffice's font folder so they'd be loaded in the same manner as before), launched Neo3, and launched John's try-server build.  I surfed with it for quite a while (including all over Alan Wood's Unicode test pages), and finally let it sit watching Tinderbox while I went to dinner...nothing.  I also had Camino 2.0b1 running at the same time (including watching Tinderbox, where Camino crashed at least once before--comment 30), and it also didn't crash.

I'm not sure what might have changed in Gecko 1.9.* such that neither a mozilla-central nor a cvs-trunk build seem to be able to cause ATS to exhibit this crash anymore.

I guess we should mark this WORKSFORME at this point, because it doesn't even seem like we can gather data to use to report the bug to Apple.  John?

Comment 42

[Matthew Middleton (:zzxc)]

I was able to reproduce this on a Mac with a mozilla-central build and with 3.0.5.  See bp-959d8eb2-1bab-4ed9-a8ce-96fe32090113 and bp-b1f7c6f6-a980-4934-9c10-375bf2090113.

I was not able to reproduce the crash after clearing the font cache, via booting the Mac in safe mode.  Confirming because this is the #15 topcrash for Firefox 3.0.5, and the #3 topcrash for 3.0.5 on Mac.

Comment 43

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The existing upstream bug about bugs in that font appears to be https://bugs.freedesktop.org/show_bug.cgi?id=18577

Comment 45

[John Daggett (:jtd)]

I think the crash in this case was fixed by the fix for bug 476504.  Has anyone seen this crash after February, when that fix was checked in?

Comment 46

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I haven't tried to reproduce it recently (and last time I tried--comment 41--I was unsuccessful in reproducing it even in a build that should have reproduced it), and definitely haven't tried in a 1.9.1-or-newer Gecko.

Comment 47

[Joe Drew (not getting mail)]

Resolving WFM per comment 46.