386584 - Crash at www.shacknews.com when changing font size [@ gfxSkipCharsIterator::SetOffsets]

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/20070702 Minefield/3.0a6pre ID:2007070204

1. New profile, start firefox
2. Go to http://www.shacknews.com/
3. Change font size with CTRL++ or CTRL+-

Firefox crashes. Talkback doesn't appear and Breakpad doesn't work with win2k so I have no stack to submit.

Will try and find a regression range.

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

I see same on Vista HP but the Breakpad did not pick up the crash. 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070702 Minefield/3.0a6pre Firefox/3.0 ID:2007070203

Comment 2

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007070118 Minefield/3.0a6pre (20070701_1817_firefox-3.0a6pre.en-US.win32.zip)
- Works (no crash when trying to change font size, although fonts don't actually change size because of bug 385224-related 'comment out the new site-specific pref code to determine perf impact' thing)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007070118 Minefield/3.0a6pre (20070701_1833_firefox-3.0a6pre.en-US.win32.zip)
Crash on font-resize (font-size change this time, after the undo of the commenting out of the site-specific pref code)

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1183339020&maxdate=1183339979

Comment 3

[philippe (part-time)]

Attachment: OS X crash log

Using a home made Camino build, made shortly after bug 386122 landed.

From the log
Thread 0 Crashed:
0   org.mozilla.camino       	0x0081dd5c gfxSkipCharsIterator::SetOffsets(unsigned, int) + 260
1   org.mozilla.camino       	0x00335e54 BuildTextRunsScanner::SetupBreakSinksForTextRun(gfxTextRun*, int, int) + 964
2   org.mozilla.camino       	0x00337f44 BuildTextRunsScanner::BuildTextRunForFrames(void*) + 4172
3   org.mozilla.camino       	0x003383e0 BuildTextRunsScanner::FlushFrames(int) + 276
4   org.mozilla.camino       	0x00338b44 BuildTextRuns(nsIRenderingContext*, nsTextFrame*, nsIFrame*, nsLineList_iterator const*) + 596
5   org.mozilla.camino       	0x00339104 nsTextFrame::EnsureTextRun(nsIRenderingContext*, nsIFrame*, nsLineList_iterator const*, unsigned*) + 656
6   org.mozilla.camino       	0x0033b8f4 nsTextFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) + 532
7   org.mozilla.camino       	0x00314d14 nsLineLayout::ReflowFrame(nsIFrame*, unsigned&, nsHTMLReflowMetrics*, int&) + 1212

Comment 4

[Peter van der Woude [:Peter6]]

If you open the page with an older build, either ctrl++ or ctrl+- and close the browser and than reopen with a current build it instantly crashes when you try to view the page. It loads fine in the background though. 

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Sounds like this is related to the content prefs service.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

I'm seeing multiple reports here.

Per the report in comment 0 and comment 2, this could be related to the content prefs code being temporarily commented out per bug 385224.  Steve, do you see a crash on builds from before the patch in bug 385224 landed?

Per comment 3, this might be related to bug 386122.  Note that Camino doesn't use the content prefs service to save site-specific prefs, as far as I know, so if this problem is happening in Camino, then it's not related to site-specific prefs (or there are two problems).

Comment 7

[Steve England [:stevee]]

> Per the report in comment 0 and comment 2, this could be related to the content
> prefs code being temporarily commented out per bug 385224.  Steve, do you see a
> crash on builds from before the patch in bug 385224 landed?

No, I see no crashes before bug 385224 landed. But I also see no crashes after it landed.

Resizing text works fine, and no crash:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007070112 Minefield/3.0a6pre (20070701_1237_firefox-3.0a6pre.en-US.win32.zip) (Pre-bug 385224)

Resizing does not work, but no crash either:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007070115 Minefield/3.0a6pre (20070701_1552_firefox-3.0a6pre.en-US.win32.zip) (Post-bug 385224)

Above range to show landing of bug 385224:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1183318620&maxdate=1183330319

Comment 8

[Martijn Wargers (dead)]

The stacktrace in comment 3 seems to indicate this is a regression from bug 367177.
Bug 385526 has a similar stacktrace.

Comment 9

[Mats Palmgren (inactive)]

Attachment: stack + data

I traced the values of mMappedFlows when the assertion occurs...

Comment 10

[Mats Palmgren (inactive)]

Attachment: fix? (diff -w)

This fixes the crash and assertions here and in bug 385526 on both Linux
and MacOSX.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That is not the right fix. We definitely want to call HasCompressedLeadingWhitespace and (possibly) mLineBreaker.AppendInvisibleWhitespace() when length is zero. That would be a situation where all the text has been collapsed away ... we still want to tell the linebreaker there was whitespace here.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The problem is misinterpretation of the content offsets for text frames when those content offsets overlap. The patch in bug 385270 fixes this by tightening invariants so that the content offsets never overlap.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

It appears that the crash I'm getting at feedhouse.mozillazine.org is the same as this one. Here's a breakpad report just in case it gives any useful information that the MacOSX one doesn't.
https://crash-reports.mozilla.com/reports/report/index/7c61500a-297a-11dc-abe7-001a4bd43e5c

Comment 15

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071608 Minefield/3.0a7pre ID:2007071608

I can't reproduce this anymore (WFM)

Comment 16

[Adam Guthrie]

There aren't any crashes in Socorro in builds after 2007-07-03-04, so I'd say some patch that landed on 2007-07-02 fixed this. 

->WORKSFORME

Comment 17

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007071605 Minefield/3.0a7pre ID:2007071605
WFM also --> VERIFIED

Comment 18

[Steve England [:stevee]]

Reopened due to backout of bug 385270

Comment 21

[Daniel Holbert [:dholbert]]

See https://bugzilla.mozilla.org/attachment.cgi?id=274720 for a reduced test case.
(attachment on bug 390417, a dup of this bug)

Comment 22

[u279076]

This bug is reproducible always on Linux with build 2007080209 for www.shacknews.com

This site appears to be pretty heavy on the flash.

Comment 25

[Gerd]

You can get Breakpad working on Windows 2000 like this:

http://code.google.com/p/google-breakpad/issues/detail?id=76#c5

Comment 27

[techtonik]

Attachment: Windows 2000 stack trace

Comment 28

[[e-mail]]

It's not crashing on me with latest build:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a8pre) Gecko/2007081604 Minefield/3.0a8pre ID:2007081604

Is it fixed with 385270?

Comment 29

[Steve England [:stevee]]

I think it can still crash, but now only if you change font sizes whilst the page is loading (ctrl-f5 and try again if it doesn't work the first time). But now the stack is different, perhaps the same as the stack in bug 389744.

Comment 30

[Myk Melez [:myk] [@mykmelez]]

I can still crash consistently with the original stack trace when changing the text size on this page: http://hgbook.red-bean.com/hgbookch1.html

Comment 31

[Martijn Wargers (dead)]

Attachment: testcase

I came up with this minimized testcase from http://hgbook.red-bean.com/hgbookch1.html
I used to crash when pressing ctrl-+ a few times, but now suddenly I'm not crashing with it anymore.

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't crash on either of these tests!

Comment 33

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #32)
> I don't crash on either of these tests!

Hmm, neither do I with today's nightly.

Comment 34

[Martijn Wargers (dead)]

You might as well close this bug.
I'm pretty sure I or someone else can come up with new crashes, if there are still potential crashes remaining.

Comment 35

[Daniel T]

I played around with the font sizes on different taps and came up with that one of the pages stopped working.

This how I did it:
1. Changed the font size so absolute smallest on http://www.mozilla.org/projects/firefox/3.0a7/releasenotes/
2. Opened a new tab and went to idg.se and changed the font size to smallest.
3. Opened a new tab and went to tbg.nu and also here changed the font size to smallest.
4. Opened a new tab and went to aftonbladet.se and changed the font size to larges and when I tried to change it back to normal it didn't work.
5. Tested to change back to normal on the other ones and it worked but not with the fourth tab.

Thought it didn't result in a crash but that the homepage stopped working that's all.

Comment 36

[Martijn Wargers (dead)]

Daniel, could you file a new bug on that issue (if there isn't one already)? Thanks.

Comment 37

[Tony Chung [:tchung]]

Verified URLs above are not crashing anymore on font size increase/decrease.  This is on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre.