Closed Bug 836236 Opened 11 years ago Closed 11 years ago
crash in _ZThn184
_N22ns Combobox Control Frame15Get Rollup Widget Ev
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
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
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
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
(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.
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?
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.
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.
Dropping qawanted based on comment 9. Please re-add if there is any new leads we can check.
It seems to be fixed.
You need to log in before you can comment on or make changes to this bug.