Closed Bug 345588 Opened 18 years ago Closed 18 years ago

Crash on reload with iExploder test 153 [@ FindSafeLength]

Categories

(Core Graveyard :: GFX, defect)

1.8 Branch
x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: j.moz, Assigned: roc)

References

()

Details

(Keywords: crash, fixed1.8.1, testcase, Whiteboard: regression from 237085)

Crash Data

Attachments

(5 files)

If you visit the url in the URL field (iExploder test 153) and reload a couple of times, the browser crashes. Trunk doesn't crash. Found using http://toadstool.se/software/iexploder/ TB21238586Y
To crash, load the testcase and hit reload a couple of times.
Blocks: iexploder
Keywords: testcase
I forgot to mention that I tested with the latest Bon Echo nightly: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060722 BonEcho/2.0b1
Can't reproduce here on the latest trunk build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060722 Minefield/3.0a1 - Build ID: 2006072204 Branch only maybe? Reporter: Is there any chance of you getting a talkbackID?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → critical
Yes, this is branch only. Seems to be much easier to crash with the original iExploder test than with the reduced testcase. It helps if you load the testcase immediately after a browser restart. Crashes from the testcase: TB21241129H TB21241146W TB21241159Z Crashes from test 153: TB21241188Y TB21241214H TB21241229E (and TB21238586Y)
This crashes at [@ FindSafeLength] and the testcase is <button> followed by lots of non-ASCII characters (1386 'Å' characters and a line feed)
Summary: Crash on reload with iExploder test 153 → Crash on reload with iExploder test 153 [@ FindSafeLength]
Incident ID: 21238586 Stack Signature FindSafeLength 59c0faad Product ID Firefox2 Build ID 2006072203 Trigger Time 2006-07-22 08:54:48.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module firefox.exe + (0050a436) URL visited User Comments Since Last Crash 164 sec Total Uptime 679 sec Trigger Reason Access violation Source File, Line No. c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/gfx/src/shared/nsRenderingContextImpl.cpp, line 516 Stack Trace FindSafeLength [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/gfx/src/shared/nsRenderingContextImpl.cpp, line 516] nsRenderingContextImpl::GetTextDimensions [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/gfx/src/shared/nsRenderingContextImpl.cpp, line 646] nsRenderingContextImpl::GetTextDimensions [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/gfx/src/shared/nsRenderingContextImpl.cpp, line 744] nsTextFrame::MeasureText [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsTextFrame.cpp, line 5504] nsTextFrame::Reflow [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsTextFrame.cpp, line 5978] nsLineLayout::ReflowFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsLineLayout.cpp, line 996] nsInlineFrame::ReflowInlineFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 690] nsInlineFrame::ReflowFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 520] nsInlineFrame::Reflow [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 434] nsLineLayout::ReflowFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsLineLayout.cpp, line 996] nsInlineFrame::ReflowInlineFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 690] nsInlineFrame::ReflowFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 520] nsInlineFrame::Reflow [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 434] nsLineLayout::ReflowFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsLineLayout.cpp, line 996] nsInlineFrame::ReflowInlineFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 690] nsInlineFrame::ReflowFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 520] nsInlineFrame::Reflow [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 434] nsLineLayout::ReflowFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsLineLayout.cpp, line 996] nsInlineFrame::ReflowInlineFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 690] nsInlineFrame::ReflowFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp, line 520] ...
Assignee: nobody → general
Component: General → GFX
Product: Firefox → Core
QA Contact: general → ian
Version: 2.0 Branch → 1.8 Branch
Can't make it crash (14 x reload) with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060722 BonEcho/2.0b1
Try saving the testcase (attachment 230269 [details]) locally and clicking on reload as fast as you can (several clicks per second).
Rapidly middle clicking on the attachment 230269 [details] link 5-10 times (loading lots of tabs in the background) also reliably crashes for me.
CCing roc, who added FindSafeLength to fix bug 237085.
Blocks: 237085
Bon Echo branch builds crash a *lot* when testing with iExploder. I left my script running for 9 hours and I got about 200 crashes (tests 1-60000). At least one third of the crashes appeared to be [@ FindSafeLength], like this one. Others were mostly null (TB21258215Z, TB21258187E) or nsFontMetricsWin::ResolveForwards (TB21258078G, TB21257963Q). So I suspect that fixing this crash might fix lots of other iExploder crashes too. This crash makes it very hard to test with iExploder so this bug is a "blocker" for me.
Flags: blocking1.8.1?
Flags: blocking1.8.1? → blocking1.8.1+
The only thing at line 516 is while (len > 0 && (IS_LOW_SURROGATE(aString[len]) || (clusterHint && !buffer[len]))) { clusterHint must be zero, because it's never set on Windows. So the crash must be the dereference of aString[len]. but len is always < aLength here. I don't know what's going on
Line numbers can be off-by-one -- talkback on at least some platforms doesn't correct for the return address being the instruction after the call.
This is the same as the previous testcase, but with automatic reload. This testcase crashes reliably within 10 reloads.
Hoping that this is useful. Sometimes I also get an assertion: ###!!! ASSERTION: internal error: 'aFont->HasGlyph(ch)', file c:/mozilla181/mozi lla/gfx/src/windows/nsFontMetricsWin.cpp, line 4333 But after that it doesn't crash, so that assertion is probably urelated, I guess.
(In reply to comment #16) > This is the same as the previous testcase, but with automatic reload. This > testcase crashes reliably within 10 reloads. Not on this side of the world :-). I still can't crash with any of the methods described here.
Oh, I bet it's Windows only
Attached patch fixSplinter Review
I bet this fixes it. Someone please confirm... It's a simple thing, we're just not setting the string length correctly for the call to 3-arg GetTextDimensions.
Assignee: general → roc
Status: NEW → ASSIGNED
Attachment #232483 - Flags: superreview?(dbaron)
Attachment #232483 - Flags: review?(dbaron)
Don't you need to fix both the char* and PRUnichar* versions?
Comment on attachment 232483 [details] [diff] [review] fix Marking this one r-, but r+sr=dbaron if you duplicate the entire patch twice to cover the other version.
Attachment #232483 - Flags: superreview?(dbaron)
Attachment #232483 - Flags: superreview-
Attachment #232483 - Flags: review?(dbaron)
Attachment #232483 - Flags: review-
Attached patch what I testedSplinter Review
Ok, that seems to fix the crash. This is what I tested with, I think this is what dbaron meant in comment 21.
Comment on attachment 232519 [details] [diff] [review] what I tested Yes, I think this is what dbaron implicitly r+sr'ed
Attachment #232519 - Flags: superreview+
Attachment #232519 - Flags: review+
roc, you're going to check this in, right? I'm not even sure it should be checked in on trunk, since it's not a problem on trunk (although I think it should still be checked in on trunk).
I will check this in on trunk and then go for branch approval. It would affect trunk Windows non-cairo builds.
Comment on attachment 232519 [details] [diff] [review] what I tested desperately needed on branches!
Attachment #232519 - Flags: approval1.8.1?
Attachment #232519 - Flags: approval1.8.0.7?
Comment on attachment 232519 [details] [diff] [review] what I tested a=dbaron. Please land on MOZILLA_1_8_BRANCH and add the fixed1.8.1 keyword once you have done so.
Attachment #232519 - Flags: superreview+
Attachment #232519 - Flags: approval1.8.1?
Attachment #232519 - Flags: approval1.8.1+
Comment on attachment 232519 [details] [diff] [review] what I tested (Would be nice to keep the indentation/spacing between the two methods the same, though.)
Attachment #232519 - Flags: superreview+
checked into 1.8.1 branch.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
I went through tests 1-45000 with the latest nightly Bon Echo build and only had 1 crash (test 31944, already filed as bug 345740) instead of dozens of crashes, so this seems fixed.
Flags: blocking1.8.0.7?
Comment on attachment 232519 [details] [diff] [review] what I tested approved for 1.8.0 branch, a=dveditz for drivers
Attachment #232519 - Flags: approval1.8.0.7? → approval1.8.0.7+
Flags: blocking1.8.0.7? → blocking1.8.0.7+
None of the local nor remote/live testcases crash for me any longer using build 2006-08-13-06 of SeaMonkey trunk on Windows XP; Verified FIXED.
Status: RESOLVED → VERIFIED
Crap...sorry, just noticed this was branch-only. /me hangs his head in shame.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
...moving right along.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Comment on attachment 232519 [details] [diff] [review] what I tested Moving this to 1.0.8 request because it's a bundle with bug 237085, which is now requested for 1.0.8.
Attachment #232519 - Flags: approval1.8.0.7+ → approval1.8.0.8?
Moving blocking nomination to 1.8.0.8... crash doesn't happen on the 1.8.0 branch unless bug 237085 is landed.
Flags: blocking1.8.0.8?
Flags: blocking1.8.0.7-
Flags: blocking1.8.0.7+
Whiteboard: regression from 237085
Restoring lost blocking flag
Flags: blocking1.8.0.9?
We're not going to take bug 237085 on the 1.8.0 branch
Flags: blocking1.8.0.9? → blocking1.8.0.9-
Comment on attachment 232519 [details] [diff] [review] what I tested don't need the regression fix if we're not taking bug 237085
Attachment #232519 - Flags: approval1.8.0.9?
Product: Core → Core Graveyard
Crash Signature: [@ FindSafeLength]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: