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

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
11 years ago
7 years ago

People

(Reporter: stevee, Unassigned)

Tracking

({regression, topcrash})

Trunk
regression, topcrash
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
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.
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
(Reporter)

Comment 2

11 years ago
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

11 years ago
Created attachment 270581 [details]
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
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. 
Sounds like this is related to the content prefs service.

Updated

11 years ago
Attachment #270581 - Attachment mime type: application/octet-stream → text/plain

Updated

11 years ago
Component: General → GFX: Thebes
OS: Windows 2000 → All
Product: Firefox → Core
QA Contact: general → thebes
Hardware: PC → All
Summary: Crash at www.shacknews.com when changing font size → Crash at www.shacknews.com when changing font size [@ gfxSkipCharsIterator::SetOffsets]
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).
(Reporter)

Comment 7

11 years ago
> 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
The stacktrace in comment 3 seems to indicate this is a regression from bug 367177.
Bug 385526 has a similar stacktrace.
Blocks: 367177

Updated

11 years ago
Component: GFX: Thebes → Layout: Fonts and Text
QA Contact: thebes → layout.fonts-and-text

Comment 9

11 years ago
Created attachment 270681 [details]
stack + data

I traced the values of mMappedFlows when the assertion occurs...
Created attachment 270682 [details] [diff] [review]
fix? (diff -w)

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

Updated

11 years ago
Blocks: 385526
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.
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.
Depends on: 385270
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
Flags: blocking1.9?
Keywords: crash → topcrash

Updated

11 years ago
Duplicate of this bug: 386763
Flags: blocking1.9? → blocking1.9+
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

11 years ago
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
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 17

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

Updated

11 years ago
Flags: in-testsuite?
(Reporter)

Updated

11 years ago
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 18

11 years ago
Reopened due to backout of bug 385270

Updated

11 years ago
Duplicate of this bug: 390690
Duplicate of this bug: 390417
See https://bugzilla.mozilla.org/attachment.cgi?id=274720 for a reduced test case.
(attachment on bug 390417, a dup of this bug)
This bug is reproducible always on Linux with build 2007080209 for www.shacknews.com

This site appears to be pretty heavy on the flash.
Flags: in-litmus?
Duplicate of this bug: 390928

Updated

11 years ago
Duplicate of this bug: 391032

Comment 25

11 years ago
You can get Breakpad working on Windows 2000 like this:

http://code.google.com/p/google-breakpad/issues/detail?id=76#c5
Duplicate of this bug: 391483

Comment 27

11 years ago
Created attachment 276762 [details]
Windows 2000 stack trace

Comment 28

11 years ago
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?
(Reporter)

Comment 29

11 years ago
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.
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
Created attachment 276972 [details]
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.
I don't crash on either of these tests!
(In reply to comment #32)
> I don't crash on either of these tests!

Hmm, neither do I with today's nightly.
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.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
No longer blocks: 390417

Comment 35

11 years ago
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.
Daniel, could you file a new bug on that issue (if there isn't one already)? Thanks.

Comment 37

11 years ago
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. 

Status: RESOLVED → VERIFIED
(Assignee)

Updated

7 years ago
Crash Signature: [@ gfxSkipCharsIterator::SetOffsets]
You need to log in before you can comment on or make changes to this bug.