403004 - Crash [@ BuildTextRunsScanner::BuildTextRunForFrames] loading Tp2 www.maktoob.com

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Ginn Chen]

See
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Ports/1194495780.1194496570.5233.gz

--- called from signal handler with signal 11 (SIGSEGV) ---
 fd786036 int nsTextFrame::GetContentEnd()const (0) + 16
 fd78846c void BuildTextRunsScanner::BuildTextRunForFrames(void*) (803f200, 803e198) + 86c
 fd786ee8 void BuildTextRunsScanner::FlushFrames(int) (803f200, 0) + f4
 fd787517 void BuildTextRunsScanner::ScanFrame(nsIFrame*) (803f200, d0eff04) + 25b
 fd787481 void BuildTextRunsScanner::ScanFrame(nsIFrame*) (803f200, d078d4c) + 1c5
 fd786a2f void BuildTextRuns(gfxContext*,nsTextFrame*,nsIFrame*,const nsLineList_iterator*) (c8f2628, cadfcfc, cadfc5c, 803f700) + 46b
 fd791fd1 void nsTextFrame::AddInlineMinWidth(nsIRenderingContext*,nsIFrame::InlineMinWidthData*) (cadfcfc, cb8a8f8, 803f6c0) + fd
 fd716e73 int nsBlockFrame::GetMinWidth(nsIRenderingContext*) (cadfc5c, cb8a8f8) + 177

Not reproducible with current www.maktoob.com.

1514       for (f = mappedFlow->mStartFrame; f != mappedFlow->mEndFrame;
1515            f = static_cast<nsTextFrame*>(f->GetNextInFlow())) {
1516         PRUint32 offset = iter.GetSkippedOffset();
1517         iter.AdvanceOriginal(f->GetContentLength());

mStartFrame, mEndFrame are not null, but mStartFrame->GetNextInFlow() is null

Comment 1

[Ginn Chen]

Attachment: testcase

minimal testcase

Comment 2

[Ginn Chen]

You've to use Arabic (Windows-1256) charset for the testcase.

Comment 3

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

Regression from the patch in bug 400826, I think. Patch coming up.

Comment 4

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

Attachment: fix

This fixes it. Simple really

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 287910 [details] [diff] [review]
fix

r+sr=bzbarsky

Comment 6

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

Basically, these mappedFlows cover a range of text frames in a continuation chain. In rare situations, there's a non-fluid continuation boundary inside the range. (These situations are rare because normally we change direction at a continuation boundary, so we would end the mappedflow and start a new textrun, but in some cases like this one the bidi resolver inserts a continuation boundary even though the direction doesn't change.)

Comment 7

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

checked in.

Comment 9

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/dcb14181bce7

Comment 10

[Gregory Szorc [:gps]]

https://hg.mozilla.org/mozilla-central/rev/dcb14181bce7