Last Comment Bug 546530 - "ASSERTION: Attempting to allocate excessively large array" with execCommand("outdent"), combining acute accent
: "ASSERTION: Attempting to allocate excessively large array" with execCommand(...
Status: RESOLVED FIXED
[sg:critical?]
: assertion, fixed1.9.0.19, testcase, verified1.9.1, verified1.9.2
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
:
Mentors:
https://bugzilla.mozilla.org/attachme...
Depends on:
Blocks: 336383 textfuzzer
  Show dependency treegraph
 
Reported: 2010-02-16 14:59 PST by :Ehsan Akhgari
Modified: 2010-07-15 13:56 PDT (History)
14 users (show)
dveditz: blocking1.9.0.19+
dveditz: wanted1.9.0.x+
roc: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.2+
.2-fixed
.9+
.9-fixed


Attachments
fix (3.63 KB, patch)
2010-02-16 17:39 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
smontagu: review+
dveditz: approval1.9.2.2+
dveditz: approval1.9.1.9+
mbeltzner: approval1.9.0.19+
Details | Diff | Splinter Review

Description :Ehsan Akhgari 2010-02-16 14:59:17 PST
+++ This bug was initially created as a clone of Bug #499844 +++

Testcase: https://bugzilla.mozilla.org/attachment.cgi?id=384527

###!!! ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp, line 69

See bug 499844 comment 14, 16 and 17.
Comment 1 :Ehsan Akhgari 2010-02-16 15:09:45 PST
Can someone with security access make this block on bug 377438 as well?  I couldn't do it because I don't have the access.
Comment 2 :Ehsan Akhgari 2010-02-16 15:14:27 PST
(In reply to bug 499844 comment #17)
> If you can explain the results of your debugging in more detail, we can
> probably work out what to do. But it might be simpler just to reassign the
> second assertion to me.

Well, there were merely observations, no results per se.

After the FindClusterStart call, the properties object's iterator start becomes 0, whereas it's 1 for iter.  Therefore, the GetSkippedDistance call returns -1.  I think that it's kind of meaningless to call GetSkippedDistance with those parameters after the FindClusterStart call, but I might be wrong.  Or maybe the code is silently assuming that FindClusterStart can never modify the iterator's start in this way, but reading its implementation, it seems sort of obvious that it does.
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-02-16 17:16:59 PST
OK. FindClusterStart walks backwards looking for the start of a cluster. The problem here is that it's walking backwards beyond the start of the text frame. We need to make it stop moving backwards when it reaches the start of the text frame.
Comment 4 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-02-16 17:39:23 PST
Created attachment 427246 [details] [diff] [review]
fix
Comment 5 Simon Montagu :smontagu 2010-02-17 09:52:21 PST
Comment on attachment 427246 [details] [diff] [review]
fix

>@@ -2460,17 +2460,17 @@ PropertyProvider::GetSpacingInternal(PRU

>         PRInt32 originalOffset = run.GetOriginalOffset() + i;
>         if (IsJustifiableCharacter(mFrag, originalOffset, isCJK)) {
>           iter.SetOriginalOffset(originalOffset);
>-          FindClusterStart(mTextRun, &iter);
>+          FindClusterStart(mTextRun, run.GetOriginalOffset(), &iter);
>           PRUint32 clusterFirstChar = iter.GetSkippedOffset();
>           FindClusterEnd(mTextRun, run.GetOriginalOffset() + run.GetRunLength(), &iter);

If you're already touching this code ... I found it hard to follow which was which of originalOffset and run.GetOriginalOffset(). Can you rename the local to iterOriginalOffset or something (or maybe use two locals, runOriginalOffset and iterOriginalOffset?)
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-02-17 12:41:45 PST
Sure.
Comment 7 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-02-24 22:39:52 PST
http://hg.mozilla.org/mozilla-central/rev/006e1e7dd7c1
Comment 8 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-02-24 22:40:53 PST
Comment on attachment 427246 [details] [diff] [review]
fix

Should be easy and safe to backport to branches.
Comment 9 Daniel Veditz [:dveditz] 2010-02-26 13:30:58 PST
Do we need this in 1.9.0 too like bug 499844?
Comment 10 Daniel Veditz [:dveditz] 2010-02-26 13:31:29 PST
Comment on attachment 427246 [details] [diff] [review]
fix

Approved for 1.9.1.9 and 1.9.2.2, a=dveditz for release-drivers
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-03-04 13:52:21 PST
Comment on attachment 427246 [details] [diff] [review]
fix

Yes.
Comment 12 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-03-04 22:55:24 PST
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/36b685937fc6
Comment 13 Mike Beltzner [:beltzner, not reading bugmail] 2010-03-05 13:35:10 PST
Comment on attachment 427246 [details] [diff] [review]
fix

a=beltzner for 1.9.0.19
Comment 14 :Ehsan Akhgari 2010-03-09 14:40:55 PST
The patch does not apply cleanly on either 1.9.1 or 1.9.0.
Comment 15 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-03-09 16:05:32 PST
There's a hunk in there that was cleaning up warnings. It's not needed for 1.9.0/1.9.1.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a0091c234b2b
Also checked into 1.9.0 CVS.
Comment 16 Al Billings [:abillings] 2010-03-12 16:26:48 PST
Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9pre) Gecko/20100312 Shiretoko/3.5.9pre. 

Verified for 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100312 Namoroka/3.6.2pre. 

One 1.9.0, built today, when I run the testcase (https://bugzilla.mozilla.org/attachment.cgi?id=384527), I see:

###!!! ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp, line 69

So, it looks like it isn't fixed on 1.9.0.

Note You need to log in before you can comment on or make changes to this bug.