Closed Bug 1380905 Opened 3 years ago Closed 2 years ago

Assertion failure: mRawPtr != nullptr (You can't dereference a NULL RefPtr with operator->().) [@mozilla::a11y::HTMLComboboxAccessible::Shutdown()]


(Core :: Disability Access APIs, defect, P2)

55 Branch



Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- fixed


(Reporter: tsmith, Assigned: eeejay)


(Blocks 1 open bug, Regression)


(Keywords: assertion, regression, testcase, Whiteboard: a11y:crash-shutdown)


(2 files)

Attached file test_case.html
I had a hard time reproducing and reducing this test case, but I finally have it! I have frequently been seeing this assertion while fuzzing for months now.

This test case may take some time (30 seconds to a minute for me) to reproduce the assertion.

Assertion failure: mRawPtr != nullptr (You can't dereference a NULL RefPtr with operator->().), at /home/worker/workspace/build/src/obj-firefox/dist/include/mozilla/RefPtr.h:315

#0 0x7ffa8679d992 in RefPtr<mozilla::a11y::DocAccessible>::operator->() const src/obj-firefox/dist/include/mozilla/RefPtr.h:314:5
#1 0x7ffa86823192 in mozilla::a11y::HTMLComboboxAccessible::Shutdown() src/accessible/html/HTMLSelectAccessible.cpp:377:3
#2 0x7ffa7e74d087 in nsCycleCollector::CollectWhite() src/xpcom/base/nsCycleCollector.cpp:3343:26
#3 0x7ffa7e74fcea in nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*, bool) src/xpcom/base/nsCycleCollector.cpp:3695:24
#4 0x7ffa7e753900 in nsCycleCollector_collectSlice(js::SliceBudget&, bool) src/xpcom/base/nsCycleCollector.cpp:4224:21
#5 0x7ffa80d1062b in nsJSContext::RunCycleCollectorSlice(mozilla::TimeStamp) src/dom/base/nsJSEnvironment.cpp:1733:3
#6 0x7ffa80d1107f in ICCRunnerFired(mozilla::TimeStamp, void*) src/dom/base/nsJSEnvironment.cpp:1792:3
#7 0x7ffa80d286ae in CollectorRunner::Run() src/dom/base/nsJSEnvironment.cpp:264:16
#8 0x7ffa80d28d91 in CollectorRunner::TimedOut(nsITimer*, void*) src/dom/base/nsJSEnvironment.cpp:281:15
#9 0x7ffa7e8ae25b in nsTimerImpl::Fire(int) src/xpcom/threads/nsTimerImpl.cpp:510:7
#10 0x7ffa7e86e8fa in nsTimerEvent::Run() src/xpcom/threads/TimerThread.cpp:286:11
#11 0x7ffa7e89f5c2 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1437:14
#12 0x7ffa7e8a5170 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:489:10
#13 0x7ffa7f409e25 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:97:21
#14 0x7ffa7f356247 in MessageLoop::RunInternal() src/ipc/chromium/src/base/
#15 0x7ffa7f3560d9 in MessageLoop::Run() src/ipc/chromium/src/base/
#16 0x7ffa83be565a in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:156:27
#17 0x7ffa86d6a4d1 in nsAppStartup::Run() src/toolkit/components/startup/nsAppStartup.cpp:287:30
#18 0x7ffa86ec60c2 in XREMain::XRE_mainRun() src/toolkit/xre/nsAppRunner.cpp:4595:22
#19 0x7ffa86ec7d1f in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4778:8
#20 0x7ffa86ec8c08 in XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4873:21
#21 0x4ecaf8 in do_main(int, char**, char**) src/browser/app/nsBrowserApp.cpp:237:22
#22 0x4ec410 in main src/browser/app/nsBrowserApp.cpp:310:16
#23 0x7ffa9c72482f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
#24 0x41e144 in _start (m-c-1499788810-asan-debug/firefox+0x41e144)
it appears we cycle collect a shutdown HTML select accessible. Technically we shouldn't shutdown an accessible twice, so it's interesting to know why that happens. On the other hand, it seems we crash at:
MOZ_ASSERT(mDoc->IsDefunct() || !mListAccessible) when accessing mDoc, 
which can be avoided by adding mDoc check.

Eitan, what is your thinking?
Assignee: nobody → eitan
I'm unassigning myself because I don't know how efficiently I can debug this.

From a quick look, it seems like we first shut down the document via 'pagehide', and then the accessible is cycle collected later on.
Assignee: eitan → nobody
Another insight, I think this has to do with an AccShowEvent that is destroyed between acc shutdown and final cycle collection. I think that may explain the racyness of this bug.
This still asserts on current trunk builds, though the assertion appears to have changed:
Assertion failure: ipcDoc, at /builds/worker/workspace/build/src/accessible/generic/Accessible.cpp:859

Regression range:
INFO: Last good revision: 79d6e9229fda9ed2076cdb1b675b2662759ee0be
INFO: First bad revision: cbce75114440f0a37d65ce3fb4725e288fc24c08
INFO: Pushlog:
Blocks: 1325834
Has Regression Range: --- → yes
Flags: in-testsuite?
Version: Trunk → 55 Branch
(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)
> This still asserts on current trunk builds, though the assertion appears to
> have changed:
> Assertion failure: ipcDoc, at
> /builds/worker/workspace/build/src/accessible/generic/Accessible.cpp:859

if this assertion doesn't hide the original one, then it's dupe of bug 1420529
Flags: needinfo?(eitan)
Whiteboard: a11y:crash-shutdown
Assignee: nobody → eitan
Flags: needinfo?(eitan)

Accessibles can be shut down twice. For example, their doc might shut
them down in its own ShutDown, while a reference is still being held by
a dispatched event. When the event goes away, or the cycle collector
kicks in, the accessible may be finally released and shut down again via

Pushed by
Allow HTMLComboboxAccessible to be shut down twice. r=Jamie
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
No longer blocks: 1325834
Flags: in-testsuite? → in-testsuite-
Regressed by: 1325834
You need to log in before you can comment on or make changes to this bug.