crash in _ZThn184_N22nsComboboxControlFrame15GetRollupWidgetEv

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: scoobidiver, Assigned: smichaud)

Tracking

({crash, regression})

19 Branch
x86_64
Mac OS X
crash, regression
Points:
---

Firefox Tracking Flags

(firefox18 unaffected, firefox19+ wontfix, firefox20+ unaffected)

Details

(crash signature)

(Reporter)

Description

6 years ago
It's #8 top browser crasher in 19.0b3 and #5 in 20.0a2 on Mac OS X.
It first showed up in 19.0a1/20121127 but has been discontinuous across builds since that.

One comment talks about a drop-down menu in http://www.yankeecandle.com/home2

Signature 	_ZThn184_N22nsComboboxControlFrame15GetRollupWidgetEv More Reports Search
UUID	aa270d9f-716a-42bd-ba63-80fa62130130
Date Processed	2013-01-30 07:35:22
Uptime	245
Last Crash	4.3 minutes before submission
Install Age	6.5 minutes since version was first installed.
Install Time	2013-01-30 07:28:43
Product	Firefox
Version	20.0a2
Build ID	20130129042016
Release Channel	aurora
OS	Mac OS X
OS Version	10.6.8 10K549
Build Architecture	amd64
Build Architecture Info	family 6 model 23 stepping 10
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x18
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x 861GL Context? GL Context+ GL Layers? GL Layers+ 
Processor Notes 	sp-processor09.phx1.mozilla.com_15932:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x 861

Frame 	Module 	Signature 	Source
0 	XUL 	_ZThn184_N22nsComboboxControlFrame15GetRollupWidgetEv 	dist/include/nsView.h:285
1 	XUL 	-[ChildView maybeRollup:] 	nsChildView.mm:2708
2 	XUL 	-[ChildView mouseDown:] 	nsChildView.mm:3153
3 	AppKit 	-[NSWindow sendEvent:] 	
4 	XUL 	-[ToolbarWindow sendEvent:] 	nsCocoaWindow.mm:2908
5 	AppKit 	-[NSApplication sendEvent:] 	
6 	XUL 	-[GeckoNSApplication sendEvent:] 	nsAppShell.mm:153
7 	AppKit 	-[NSApplication run] 	
8 	XUL 	nsAppShell::Run 	nsAppShell.mm:741
9 	XUL 	nsAppStartup::Run 	nsAppStartup.cpp:288
10 	XUL 	XREMain::XRE_mainRun 	nsAppRunner.cpp:3823
11 	XUL 	XREMain::XRE_main 	nsAppRunner.cpp:3890
12 	XUL 	XRE_main 	nsAppRunner.cpp:4093
13 	firefox 	main 	nsBrowserApp.cpp:195
14 	firefox 	start 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=_ZThn184_N22nsComboboxControlFrame15GetRollupWidgetEv
(Assignee)

Comment 1

6 years ago
Likely a dup of bug 682208.  Or at least a variant of it.
See Also: → bug 682208
(Assignee)

Comment 2

6 years ago
c++filt demangles __ZThn184_N22nsComboboxControlFrame15GetRollupWidgetEv to nsComboboxControlFrame::GetRollupWidget().  Interestingly, there are also a bunch of crashes at nsComboboxControlFrame::GetRollupWidget() on Windows:

https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=RollupWidget&reason_type=contains&date=01%2F30%2F2013%2018%3A18%3A54&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsComboboxControlFrame%3A%3AGetRollupWidget%28%29
(Assignee)

Comment 3

6 years ago
These crashes go back several months (on both Windows and the Mac), but they've increased in frequency more recently.

Here are the oldest builds I can find with this crash:

20121028030617 (Windows)
https://crash-stats.mozilla.com/report/index/db651f31-e957-444b-b338-67a762121028
20121030030633 (Mac)
https://crash-stats.mozilla.com/report/index/ad10877f-f862-441b-acc4-acb6a2121109

Comment 4

6 years ago
Sending over to you Steven, since you're already investigating and looking at bug 682208.

Also adding qawanted to perform exploratory testing around http://www.yankeecandle.com/home2
Assignee: nobody → smichaud
tracking-firefox19: ? → +
tracking-firefox20: ? → +
Keywords: qawanted, steps-wanted
QA Contact: jbecerra

Comment 5

6 years ago
(In reply to Steven Michaud from comment #1)
> Likely a dup of bug 682208.  Or at least a variant of it.

Not sure, as this is here only since 19, and the other affects 18 as well.

(In reply to Steven Michaud from comment #2)
> Interestingly, there are also a
> bunch of crashes at nsComboboxControlFrame::GetRollupWidget() on Windows

That one seems to only exist since 19.

Neil Deakin was the last person to change nsComboboxControlFrame.cpp so CCing him as well.
(Assignee)

Comment 6

6 years ago
I think it's likely this bug's crashes were caused by the patch for bug 701760, which landed on mozilla-central on 2012-10-26 (just a few days before the earliest builds I mentioned in comment #3).  Though a bad interaction with a subsequent patch may have increased the frequency of the crashes.

I've found a likely cause in nsComboboxControlFrame::GetRollupWidget(), which I've patched at bug 682208 comment #41.  We'll see what comes of that.

I now agree this bug can't literally be a dup of bug 682208.  But take away this crash's top frame (on the Mac) and they look identical to those for bug 682208.  So I'll bet the recent upsurge of bug 682208-style crash stacks is in fact this bug (they're just missing their top frame).
I tried reproducing this with the steps in https://bugzilla.mozilla.org/show_bug.cgi?id=682208#c26 but I haven't been able to crash.
Thanks for trying, Juan.

Steven, given QA's unsuccessful attempts to reproduce this crash and the progress you noted in comment 6, is there any other assistance QA can provide on this bug?
(Assignee)

Comment 9

6 years ago
I'm almost certain this bug will get fixed along with bug 682208 and bug 837047.  So there's probably nothing more we need to do here.
(Reporter)

Comment 10

6 years ago
The latest crashes happened in 20.0a2/20130206 for Aurora.
(In reply to Steven Michaud from comment #6)
> I think it's likely this bug's crashes were caused by the patch for bug
> 701760, which landed on mozilla-central on 2012-10-26 (just a few days
> before the earliest builds I mentioned in comment #3).  Though a bad
> interaction with a subsequent patch may have increased the frequency of the
> crashes.

Performing a backout of bug 701760 does look risky at this point.

(In reply to Steven Michaud from comment #9)
> I'm almost certain this bug will get fixed along with bug 682208 and bug
> 837047.  So there's probably nothing more we need to do here.

Agreed - looks like this'll be first resolved in FF20.
status-firefox19: affected → wontfix
(Reporter)

Updated

6 years ago
Keywords: topcrash
Dropping qawanted based on comment 9. Please re-add if there is any new leads we can check.
Keywords: qawanted
(Reporter)

Comment 13

6 years ago
It seems to be fixed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-firefox20: affected → unaffected
Keywords: steps-wanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.