2.19 KB, text/plain
89.27 KB, text/plain
14.34 KB, text/plain
3.63 KB, text/plain
3.62 KB, text/plain
82.68 KB, text/plain
760 bytes, text/plain
36.27 KB, text/plain
1.37 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en; rv:22.214.171.124pre) 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:126.96.36.199pre) 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.
Between the crash logs and the talkback IDs, I hope you can find it.
Version: unspecified → Trunk
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?
Component: General → GFX: Thebes
Product: Camino → Core
QA Contact: general → thebes
Summary: crash on opening Wikipedia main page → crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page
Version: Trunk → 1.9.0 Branch
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.
Oscar, what are your font settings? I can't seem to reproduce this myself.
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).
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.
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.
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.
Created attachment 343702 [details] history.dat excerpt I added a history.log excerpt. I stripped away everything from before the latest crash.
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)
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
Created attachment 343790 [details] 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.
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.
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.
So far, the crash hasn't appeared yet since I cleaned the font cache. Fingers crossed!
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.
Patrick Luby, developer of NeoOffice, suggested another test. I have done as he suggested, and I will report back in a few days.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
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?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page → crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page because of OOo's Deja Vu and Liberation fonts
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.
*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.
Summary: crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page because of OOo's Deja Vu and Liberation fonts → crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page because of ooo-build's Deja Vu and Liberation fonts
(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.
(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.
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.
I'll try a debug build, no problem.
Created attachment 350928 [details] [diff] [review] 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.
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:firstname.lastname@example.org/ 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.
****, 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 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.
(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)
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.
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.
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...
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..
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?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page because of ooo-build's Deja Vu and Liberation fonts → crash [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] on opening Wikipedia main page because of OpenOffice.org's corrupt font (Deja Vu Sans Extra Light)
The existing upstream bug about bugs in that font appears to be https://bugs.freedesktop.org/show_bug.cgi?id=18577
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?
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.
Crash Signature: [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth]
Resolving WFM per comment 46.
Status: NEW → RESOLVED
Crash Signature: [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth] → [@ 0xfffeff20] [@ gfxAtsuiFont::GetCharWidth]
Last Resolved: 10 years ago → 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.