This table does not load

VERIFIED DUPLICATE of bug 17372

Status

()

P3
major
VERIFIED DUPLICATE of bug 17372
19 years ago
19 years ago

People

(Reporter: teruko, Assigned: buster)

Tracking

Trunk
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
When you try to load this table, Mozilla.exe will hang.

Steps of reproduce
1. Go to above url

The status bar says "Transfering data from babel", then Mozilla.exe will hang.

This page used to load correctly.
Tested 11-02-08 Win32 and Mac, and 11-02-12 Linux build.
URL is not accessible to me, could you add it as an attachment ? Thanks.
(Reporter)

Comment 2

19 years ago
Created attachment 2578 [details]
test table
(Reporter)

Updated

19 years ago
Assignee: karnaze → ftang
Severity: normal → major
Component: HTMLTables → Internationalization
QA Contact: chrisd → teruko
(Reporter)

Comment 3

19 years ago
*** Bug 17874 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11

Updated

19 years ago
Assignee: ftang → nhotta
Status: ASSIGNED → NEW

Comment 4

19 years ago
naoki, please help to look at this.

Comment 5

19 years ago
Yes, the bug I filed seems to be a duplicate of this one.
But what I said there still holds. We need to find out why.
The page contains pretty much the entire 8-bit codepoints
0x20 - 0xFF. One possibility is that one or more of the codepoints
are cauing this freeze. If so, we'd better find out before M11
ships.

Comment 6

19 years ago
Created attachment 2580 [details]
stack at point of the crash, used yesterday's pull

Comment 7

19 years ago
It crashed on my local build (stack dump attached). Before crash, it asserts
many times in the frame code (at least 30, so I disabled it). I don't see any
i18n specific problem so far. Can somebody modify the html and put 256 'a'
instead then try?

Comment 8

19 years ago
nhotta, don't waste you time here to find out the crash. Do the following
1. reenable the Assert.
2. When you first assert, copy and paste the stack to this bug report.
3. Find the line which cause the assert.
4. use cvsblame find who touch that line
5. reaissgn this bug to that guy and ask him/her to look at it.
The assert tell you something wrong. The problem is THERE when you hit the
assert. Don't wait till it crash.

Comment 9

19 years ago
Created attachment 2583 [details]
stack dump at point of the assertion in nsBlockFrame

Updated

19 years ago
Assignee: nhotta → troy

Comment 10

19 years ago
Attached the stack trace at the assersion in nsBlockFrame.
Reassign to troy, cc to kipp.

Updated

19 years ago
Assignee: troy → kipp

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 11

19 years ago
*** This bug has been marked as a duplicate of 17372 ***
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 12

19 years ago
Verified as dup.
You need to log in before you can comment on or make changes to this bug.