table crash [@ BCMapCellIterator::SetInfo] [@ nsTableFrame::GetEffectiveColSpan]




14 years ago
8 years ago


(Reporter: jruderman, Assigned: bernd_mozilla)


(Blocks 1 bug, {crash, verified1.8})

Dependency tree / graph
Bug Flags:
blocking1.8b5 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:fix], crash signature)


(4 attachments, 1 obsolete attachment)

Whiteboard: [sg:fix]

Can I add Martin Wargers to security related bugs, he is a testcase createur
Assignee: nobody → bernd_mozilla
I managed to reduce it a bit further, but it is still not minimal.
When you get a slow script warning, just continue.
After the page has finished consuming all cpu, click once in the page to get
the crash.
The style table  { border-collapse: collapse;  } seems also necessary to
trigger the crash.
This is how the dom source looks like of the parentNode of allNodes[60] just
before the crash. allNodes[60] is the second td.
I see the crash with attachment 196333 [details] as described in comment 4
Flags: blocking1.8b5?
I tried today to get this testcase down to something reasonable, but failed. Is
there any known way how to rewind these random things into something usefull?
With the attached testcase its impossible for me to debug this.
Flags: blocking1.8b5? → blocking1.8b5+
Martijn, that testcase is great, its reasonable small, crashes and is  debugable.
Posted patch patch (obsolete) — Splinter Review
Bernd, is this patch ready for review?
I need to rtest the patch and to add some comments at least to the bug or better
to the source to get this into a shape where I can ask Boris to review this.
Posted patch patchSplinter Review
The problem here is that rebuild cellmap relied on Appendcells to increase the
mRowCount. This fails if an empty row is in the table, as AppendCells will not
be called in this case. Only  when the rows are to be added or to be removed we
know for certain that they are real and not dead rows so putting the burden
here at AppendCells is wrong.
Attachment #196926 - Attachment is obsolete: true
Attachment #197277 - Flags: superreview?(bzbarsky)
Attachment #197277 - Flags: review?(bzbarsky)
Attachment #197277 - Flags: superreview?(bzbarsky)
Attachment #197277 - Flags: superreview+
Attachment #197277 - Flags: review?(bzbarsky)
Attachment #197277 - Flags: review+
fix checked in
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 197277 [details] [diff] [review]

Did this land on trunk or branch?
Attachment #197277 - Flags: approval1.8b5?
This has so far landed on trunk but not branch.
Attachment #197277 - Flags: approval1.8b5? → approval1.8b5+
I am not sure that I will be able to checkin before friday, if this is urgent
then please check it in before.
fixed on branch
Keywords: fixed1.8
Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5)
Gecko/20050928 Firefox/1.4, I still crash using the first test case, as well as
the fourth test case. Reopening. Talkback ID is TB9840133M for the first
testcase. Running OSX 10.4.2.
Resolution: FIXED → ---
resolving fixed again - I will test tomorrow. Misread the checkin date. sorry.
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Looks good using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8b5) Gecko/20050929 Firefox/1.4. No crashes with any of the test cases. If
I run the first test case, Firefox does throw up an alert "Unresponsive script."
Is this expected?
Flags: testcase+
Group: security
Summary: StirDOM/table crash [@ BCMapCellIterator::SetInfo] [@ nsTableFrame::GetEffectiveColSpan] → table crash [@ BCMapCellIterator::SetInfo] [@ nsTableFrame::GetEffectiveColSpan]
Flags: in-testsuite+ → in-testsuite?
crash test landed
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ BCMapCellIterator::SetInfo] [@ nsTableFrame::GetEffectiveColSpan]
You need to log in before you can comment on or make changes to this bug.