Closed Bug 354645 Opened 18 years ago Closed 17 years ago

Crash [@ nsBoxFrame::AppendFrames] removing <xul:tabs> during onselect

Categories

(Core :: XBL, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: sicking)

References

Details

(4 keywords, Whiteboard: [sg:critical] fixed by 267833)

Crash Data

Attachments

(1 file)

552 bytes, application/vnd.mozilla.xul+xml
Details
Loading this testcase makes Firefox (debug) crash with

0xdddddddc
nsBoxFrame::AppendFrames
nsFrameManager::AppendFrames
nsCSSFrameConstructor::AppendFrames
...

Nightlies crash too, but with a slightly different stack trace.
Attached file testcase
Whiteboard: [sg:critical]
Flags: blocking1.9?
I can reproduce on the Firefox 2 branch, too, so nominating for blocking1.8.1.
Flags: blocking1.8.1?
Flags: blocking1.8.1.1?
Too late for this type of thing, should fix for 1.8.1.1
Flags: blocking1.8.1? → blocking1.8.1-
Usual problem -- the XBL constructor is run while the frame tree is not yet done being constructed, it does some stuff, said stuff triggers a select event firing, which removes the node from the tree (and destroys its frames).  Then we unwind and attempt to insert said deleted frames into the tree, dereference 0xdddddddd (in debug builds, or random memory in opt builds), and crash.
Depends on: 267833
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1+
Assignee: nobody → general
Component: XP Toolkit/Widgets: XUL → XBL
QA Contact: xptoolkit.xul → ian
Flags: blocking1.8.1.1+
Does this happen in 1.8.0.x as well?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10? → blocking1.8.0.10+
Jonas:  Can you take a look at this? 
Assignee: general → bugmail
By bzs description I don't think we should try to fix this one particular crash since there's a bigger general issue that can cause many different types of crashes. I.e. that we run XBL ctors at unsafe times. I'll try to look in to that issue as i'm whacking XBL and nsCSSFrameCtor interaction in general.
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10+
does the "whacking XBL and nsCSSFrameCtor interaction in general" work have bugs or a spec to help tracking the work and its possible impact on fixing this one?  be good to add those links here.
Keywords: arch
Marking blocking for now. Hopefully the fix for 267833 will fix this one.
Flags: blocking1.9? → blocking1.9+
Doesn't crash now (probably due to the patch in bug 267833).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13+
Moving out to 1.8.1.6 following bug 267833
Flags: blocking1.8.1.5+ → blocking1.8.1.6+
Whiteboard: [sg:critical] → [sg:critical] fixed by 267833
Flags: blocking1.8.0.13+ → blocking1.8.0.14?
bug 267833 landed on the branch, fixed1.8.1.8
Keywords: fixed1.8.1.8
verified fixed 1.8.1.8 using : Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.8) Gecko/2007100816 Firefox/2.0.0.8 - no crash on testcase - adding verified keyword
Group: security
Flags: blocking1.8.0.14? → blocking1.8.0.15?
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2007123104 Minefield/3.0b3pre and the testcase from this bug - no crash on testcase

-> Verified fixed
Status: RESOLVED → VERIFIED
Flags: blocking1.8.0.15? → blocking1.8.0.15+
Crash Signature: [@ nsBoxFrame::AppendFrames]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: