1.01 KB, text/html
2.56 KB, text/plain
1.53 KB, patch
|Details | Diff | Splinter Review|
Created attachment 323206 [details] testcase The page in http://www.haaretz.co.il/hasite/spages/988750.html crashes Firefox: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008053002 Minefield/3.1a1pre This is with 10.5.2. I'll test this on Intel/10.5.3 later and report. Crasher report ID: 18e158a3-2ef6-11dd-8f1f-001cc4e2bf68 After much minimizing efforts, it seems that the following conditions have to be met for the page to crash: - Font should be Arial. - There must be a line consisting of 510 characters exactly, which could be Hebrew letters, spaces, and punctuation. - All words on the line should be unique, and nut not appear earlier on the page. - Words that aren't unique, or that appeared earlier on the page, simply don't count towards the 510 character count (so you can add a word to the 510-chars line and still have it crash if you also add it somewhere before the line).
Regression range is 2008-01-28 to 2008-01-29: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-28+03%3A00&maxdate=2008-01-29+05%3A00&cvsroot=%2Fcvsroot Bug 410728 seems like a possible candidate for causing this. Nominating to block 22.214.171.124 since this is a fairly recent crash regression encountered in real world.
Flags: wanted1.9.0.x? → blocking126.96.36.199?
This doesn't crash on Intel/10.5.3. When I get back to my PPC machine, I'll try to upgrade it to 10.5.3 and see if that helps.
http://crash-stats.mozilla.com/report/index/18e158a3-2ef6-11dd-8f1f-001cc4e2bf68 Looks like it crashes deep in ATS. Probably an ATS bug, especially given it works in 10.5.3 (and 10.4.11 for me); maybe it was a 10.5 bug fixed in 10.5.3?
Still crashing on this with my PPC machine after upgrading to 10.5.3: http://crash-stats.mozilla.com/report/index/2d12e178-3483-11dd-9ea0-001cc4e2bf68?p=1
After removing a version of Arial I had in my account's Fonts directory, I'm now also crashing on the Intel/10.5.3 machine: http://crash-stats.mozilla.com/report/index/ca6a678c-34a0-11dd-997e-001cc4e2bf68?p=1 I wasn't, however, able to get a crash on a 10.4.11 machine.
Confirmed crash on 10.5.3 Intel with RC2: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0 Mac OS X 10.5.3 (9D34)
Assignee: nobody → jdaggett
Created attachment 324286 [details] Code that crashes This is a minimized C++/Carbon standalone program that produces the same crash. As far as I can tell, this means that this is indeed an ATSUI bug (in 10.5). However, we might want to consider ways to work around it and avoid the crash.
Thanks Uri!!! Can you report the bug to Apple? We can probably work around it just by having GuessMaximumStringLength max out at 500 or so. Can you try that?
Created attachment 324385 [details] code that crashes, lookup ATSUFontIDs by name Yeah, this code is a huge help!! ATSUFontIDs are not fixed, so I changed the code to lookup the fonts via the Postscript name. I'll log a bug with Apple and ping the ATSUI engineer, I'm sure he loves hearing about these bugs. ;)
Attachment #324286 - Attachment is obsolete: true
Created attachment 324387 [details] [diff] [review] initial patch, cap GuessMaximumStringLength at 500 needs more testing but the testcase no longer crashes with this
Logged as Apple bug 5996598.
Status: NEW → ASSIGNED
Testcase stack crawl: #0 0x93797bc4 in OTL::GCommon::GetLookups () #1 0x9374a2d2 in ProcessRunCommon () #2 0x93749d6f in ProcessGSUBRun () #3 0x9373ae3b in ApplyMorphForRun () #4 0x9374728f in ApplyMorph () #5 0x9373a20f in _eLLCLayoutText () #6 0x9373a0c3 in LLCLayoutText () #7 0x92e433e2 in ATSULayoutGlyphs () #8 0x92e432ce in TTextLineLayout::LayoutGlyphVector () #9 0x92e543de in TTextLineLayout::EnsureLayoutIsUpToDate () #10 0x92e5eecd in TTextLineLayout::GetGlyphBounds () #11 0x92e5edfe in ATSUGetGlyphBounds () #12 0x00001f37 in main (argc=1, argv=0xbffff7b8) at /Users/jd/Desktop/test/atsuistrcrash/main.cpp:79
Note from Apple ATSUI dev: "I believe we already fixed this crasher in SnowLeopard. If I can reproduce and show the fix on Leopard, I can probably get it into an SU. Thanks." SnowLeopard is 10.6, due out next year(?).
John, are you going to ask for review on your patch? I'm crashing on this every once in a while, and it's very annoying.
Tested with latest 10.5 update (Mac OS X 10.5.5 (9F33)), not fixed.
Created attachment 339010 [details] [diff] [review] patch, v.0.2, cap string length only on 10.5
(In reply to comment #15) > John, are you going to ask for review on your patch? I'm crashing on this every > once in a while, and it's very annoying. Once this has been reviewed and checked in on trunk, I'll work on getting this approved and back ported to 1.9.0.x.
Comment on attachment 339010 [details] [diff] [review] patch, v.0.2, cap string length only on 10.5 Workaround looks fine to me.
Attachment #339010 - Flags: superreview?(vladimir) → superreview+
Comment on attachment 339010 [details] [diff] [review] patch, v.0.2, cap string length only on 10.5 ugh
Attachment #339010 - Flags: review?(roc) → review+
Checked in 505564b8749d 2008-09-26 16:51 +0900
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081013 Minefield/3.1b2pre. I verified using the testcase in Comment 0.
Status: RESOLVED → VERIFIED
Comment on attachment 339010 [details] [diff] [review] patch, v.0.2, cap string length only on 10.5 John, can you comment as to risk for branch and request approval for 188.8.131.52 if its still appropriate?
Attachment #339010 - Flags: approval184.108.40.206? → approval220.127.116.11-
Comment on attachment 339010 [details] [diff] [review] patch, v.0.2, cap string length only on 10.5 (In reply to comment #23) > (From update of attachment 339010 [details] [diff] [review]) > John, can you comment as to risk for branch and request approval for 18.104.22.168 if > its still appropriate? This is a low-risk patch since we are just working around an underlying Apple bug. I spoke with Uri about this at the summit, he said he experienced this relatively frequently, so I imagine Hebrew users are hitting this fairly often.
Attachment #339010 - Flags: approval22.214.171.124?
Comment on attachment 339010 [details] [diff] [review] patch, v.0.2, cap string length only on 10.5 Approved for 126.96.36.199, a=dveditz for release-drivers
Attachment #339010 - Flags: approval188.8.131.52? → approval184.108.40.206+
Checked in on cvs trunk.
Duplicate of this bug: 463910
Verified for 220.127.116.11 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:18.104.22.168pre) Gecko/2008120104 GranParadiso/3.0.5pre. Verified the crash with a Firefox 3.0.4 instance.
Keywords: fixed22.214.171.124 → verified126.96.36.199
Fixed in 10.6, SL seed 10A222. Trying to see if the fix can be backported to 10.5.
Crash Signature: [@ OTL::GCommon::GetLookups]
You need to log in before you can comment on or make changes to this bug.