Crash [@ nsLineBox::DeleteLineList] when hovering over select in this evil testcase

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
--
critical
VERIFIED FIXED
13 years ago
7 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: mats)

Tracking

({crash, testcase})

Trunk
x86
Windows 2000
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xul frame construction], crash signature)

Attachments

(4 attachments)

458 bytes, application/vnd.mozilla.xul+xml
Details
573 bytes, application/vnd.mozilla.xul+xml
Details
611 bytes, application/vnd.mozilla.xul+xml
Details
2.05 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

13 years ago
See upcoming testcase.
When hovering over the select dropdown, Mozilla crashes.
This also happens in Mozilla1.7, so no (recent) regression.
(Reporter)

Comment 1

13 years ago
Created attachment 174677 [details]
Testcase

From Talkback ID TB3777572K:

nsLineBox::DeleteLineList 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsLineBox.cpp,
line 318]
nsLineBox::DeleteLineList 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsLineBox.cpp,
line 318]
nsFrameList::DestroyFrames 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsFrameList.cpp,
line 129]
nsFrameList::DestroyFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsFrameList.cpp,
line 223]
nsFrameManager::RemoveFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsFrameManager.cpp,
line 736]
nsCSSFrameConstructor::ContentRemoved 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 9935]
nsCSSFrameConstructor::RecreateFramesForContent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 11761]
nsCSSFrameConstructor::RestyleElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 10332]
nsCSSFrameConstructor::ProcessOneRestyle 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13738]
nsCSSFrameConstructor::ProcessPendingRestyles 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13783]
nsCSSFrameConstructor::RestyleEvent::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13835]
SETUPAPI.DLL + 0x30c24 (0x778b0c24)
(Reporter)

Updated

13 years ago
Severity: normal → critical

Updated

13 years ago
Keywords: crash

Comment 2

13 years ago
I just used this bug to check this nightlies talkback for Mozilla, got the same
stack:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3781872G

It is also crashing with Mozilla 1.0.2, 1.4.2 and 1.6
Whiteboard: [xul frame construction]

Comment 3

13 years ago
Created attachment 177034 [details]
testcase crash onload without hover

Comment 4

13 years ago
Martijn, I just tested this one with DP alpha2 winxp: WFM?
(Reporter)

Comment 5

13 years ago
For me it is still crashing with 20050902 trunk build.

Comment 6

13 years ago
identical talkbacks:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050902 SeaMonkey/1.1a
TB8993785Y 1st testcase

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1
TB8993838Q 1st testcase

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050902 Firefox/1.6a1
TB8994014H, TB8993989W 2nd+1st testcase

Comment 7

13 years ago
Created attachment 194776 [details]
table free testcase

Comment 8

13 years ago
as this crashes within form control code and does not require table elements
around it I guess its more a form control issue. Maybee Mats knows how to deal
with this.
Component: Layout: Tables → Layout: Form Controls
QA Contact: layout.tables → layout.form-controls
(Assignee)

Comment 9

13 years ago
Created attachment 194820 [details] [diff] [review]
Patch rev. 1

'mDisplayFrame' is supposed to be a privately allocated frame that we destroy
in 'nsComboboxControlFrame::Destroy' so assigning it here is just plain wrong.
We crash since we point into the AreaFrame child list and thus Destroy will
be called twice.
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Attachment #194820 - Flags: superreview?(bzbarsky)
Attachment #194820 - Flags: review?(bzbarsky)
Comment on attachment 194820 [details] [diff] [review]
Patch rev. 1

Er... how are we ending up with random frames in any case here?

r+sr=bzbarsky, but this code could really use some cleanup (eg why do we have
two codepaths for creating mDisplayFrame?  And as I said, how is this ending up
with random frames anyway?).
Attachment #194820 - Flags: superreview?(bzbarsky)
Attachment #194820 - Flags: superreview+
Attachment #194820 - Flags: review?(bzbarsky)
Attachment #194820 - Flags: review+
(Reporter)

Comment 11

13 years ago
Mats, the patch has r+ and sr+, so you could check this in (in case you forgot
this bug).
(Reporter)

Updated

13 years ago
Whiteboard: [xul frame construction] → [xul frame construction][checkin needed]
I checked the patch in on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Whiteboard: [xul frame construction][checkin needed] → [xul frame construction]
Verified FIXED using build 2005-12-09-09 of SeaMonkey trunk on Windows XP with all 3 testcases.

Note: the movement of the <select> on hover in https://bugzilla.mozilla.org/attachment.cgi?id=174677 has already been filed.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsLineBox::DeleteLineList]
You need to log in before you can comment on or make changes to this bug.