451198 - Hang and crash [@ BuildTextRunsScanner::BuildTextRunForFrames] with dd and iframe with binding

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

This is split off from bug 432813.

The url testcase is zipped.

With current trunk build, it hangs.

It doesn't seem to have the regression range, which would point to bug 366770 (between 2007-02-24/2007-02-25). It just uses a lot of cpu in those builds, while the iframe keeps shaking.
Let me know, if a regression range for the hang would be useful.

Comment 1

[Martijn Wargers (dead)]

I just noticed that if you let the testcase hang for a while (>20s), Mozilla crashes:
http://crash-stats.mozilla.com/report/index/fff4619c-6e04-11dd-9e81-001a4bd43e5c?p=1
Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	_chkstk 	chkstk.asm:99
1 	xul.dll 	BuildTextRunsScanner::BuildTextRunForFrames 	layout/generic/nsTextFrameThebes.cpp:1711
2 	xul.dll 	BuildTextRunsScanner::FlushFrames 	layout/generic/nsTextFrameThebes.cpp:1114
3 	xul.dll 	xul.dll@0x2cdd40 	
4 	xul.dll 	BuildTextRuns 	layout/generic/nsTextFrameThebes.cpp:1031
5 	xul.dll 	nsTextFrame::EnsureTextRun 	layout/generic/nsTextFrameThebes.cpp:1871
6 	xul.dll 	nsTextFrame::Reflow 	layout/generic/nsTextFrameThebes.cpp:5740
7 	xul.dll 	nsLineLayout::ReflowFrame 	layout/generic/nsLineLayout.cpp:853
8 	xul.dll 	nsBlockFrame::ReflowInlineFrame 	layout/generic/nsBlockFrame.cpp:3585
9 	xul.dll 	nsBlockFrame::DoReflowInlineFrames 	layout/generic/nsBlockFrame.cpp:3408
etc..

Comment 2

[Johnny Stenback (:jst)]

This looks like a reflow crash, over to layout.

Comment 3

[Boris Zbarsky [:bzbarsky]]

A regression range for the hang would in fact be nice.

Comment 4

[Martijn Wargers (dead)]

Sorry for the delay, this regressed between 2007-09-20 and 2007-09-21:
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=2007-09-20+04&maxdate=2007-09-21+06&cvsroot=%2Fcvsroot
A regression from bug 396099 somehow perhaps?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Possible (though unlikely), but if so it just exposes another latent bug that could have been triggered in other ways... :(

Comment 6

[Timothy Nikkel (:tnikkel)]

Bug 507991 will fix this specific testcase, but by changing the id of the
binding URI inside the <style> in the binding document (to any binding id that doesn't exist for example) there is still a problem.

Comment 7

[Mats Palmgren (inactive)]

WFM, Nightly 41.0a1 (2015-05-29) on Linux64.  (also after modifying the test per comment 6)
FWIW, the signature has zero incidents on crash-stats in the past 28 days.

Martijn, can you still reproduce this crash in a recent version?

Comment 8

[Martijn Wargers (dead)]

Yes, seems to be WFM in current trunk build on MacOSX 10.9.5. (also tried the thing in comment 6)