Closed Bug 1380905 Opened 2 years ago Closed 5 months ago

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

Categories

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

55 Branch
defect

Tracking

()

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

People

(Reporter: tsmith, Assigned: eeejay)

References

(Blocks 1 open bug, Regression)

Details

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

Attachments

(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/message_loop.cc:320:10
#15 0x7ffa7f3560d9 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:293:3
#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:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=79d6e9229fda9ed2076cdb1b675b2662759ee0be&tochange=cbce75114440f0a37d65ce3fb4725e288fc24c08
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
LastRelease.

Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9d7773bd3ae7
Allow HTMLComboboxAccessible to be shut down twice. r=Jamie
Status: NEW → RESOLVED
Closed: 5 months 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.