Closed Bug 413388 Opened 17 years ago Closed 16 years ago

"ASSERTION: Some objects allocated with AllocateFrame were not freed" with -moz-column, inline-block

Categories

(Core :: Layout, defect, P3)

x86
macOS
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Assigned: roc)

References

Details

(4 keywords, Whiteboard: [sg:critical?][cannot reproduce])

Attachments

(1 file)

828 bytes, application/xhtml+xml
Details
Attached file testcase
Closing (or reloading) the testcase triggers: ###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed: 'mFrameCount == 0', file /Users/jruderman/trunk/mozilla/layout/base/nsPresShell.cpp, line 673 This appears to be exploitable in the usual way. (Also, the letter 't' fails to appear.)
Flags: blocking1.9?
Blocks: framedest
Whiteboard: [sg:critical?]
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee: nobody → roc
For some reason we create a fifth column here during reflow, which is rather strange.
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: tracking1.9+
I can still reproduce this bug on trunk.
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: P2 → P3
WFM on trunk. It doesn't even assert.
Whiteboard: [sg:critical?] → [sg:critical?][cannot reproduce]
WFM here too.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Flags: wanted1.9.0.x-
Flags: wanted1.9.0.x+
Flags: blocking1.9.1+
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: