1657031 - Observe b2g crash due to mParentEventTargetRef is null

Status: RESOLVED INVALID

(Core :: DOM: Workers, defect, P3)

Description

[Vincent Chang[:vchang][changyihsin]]

Here is the backtrace, b2g process is crashed sometimes during device boot up.

#0 nsWrapperCache::GetWrapperPreserveColor (this=0x4) at gecko/dom/base/nsWrapperCacheInlines.h:14
#1 0xa45c67cc in nsWrapperCache::GetWrapper (this=0x4) at /objdir-gecko/dist/include/nsWrapperCacheInlines.h:27
#2 0xa5845abe in mozilla::dom::WorkerRunnable::Run (this=0x9ba45ee0) at /gecko/dom/workers/WorkerRunnable.cpp:345
#3 0xa45c1334 in mozilla::ThrottledEventQueue::Inner::ExecuteRunnable (this=0x9e888a60)
at /gecko/xpcom/threads/ThrottledEventQueue.cpp:254
#4 mozilla::ThrottledEventQueue::Inner::Executor::Run (this=)
at /gecko/xpcom/threads/ThrottledEventQueue.cpp:81
#5 0xa600900c in mozilla::tasktracer::TracedRunnable::Run (this=0x9ba25430)
at /gecko/tools/profiler/tasktracer/TracedTaskCommon.cpp:101
#6 0xa45b4d0a in mozilla::RunnableTask::Run (this=0x9beae5c0) at /gecko/xpcom/threads/TaskController.cpp:242
#7 0xa45b4422 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal (this=0xac069940, aProofOfLock=...)
at /gecko/xpcom/threads/TaskController.cpp:512
#8 0xa45b39ec in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal (this=0xac069940, aProofOfLock=...)
at /gecko/xpcom/threads/TaskController.cpp:371
---Type to continue, or q to quit---
#9 mozilla::TaskController::ProcessPendingMTTask (this=0xac069940, aMayWait=false)
at /gecko/xpcom/threads/TaskController.cpp:168
#10 0xa45b62d4 in mozilla::TaskController::InitializeInternal()::$_4::operator()() const (this=)
at /gecko/xpcom/threads/TaskController.cpp:83
#11 mozilla::detail::RunnableFunction::Run() (this=)
at /objdir-gecko/dist/include/nsThreadUtils.h:577
#12 0xa45bc89a in nsThread::ProcessNextEvent (this=0xac0582e0, aMayWait=, aResult=0xbea251e3)
at /gecko/xpcom/threads/nsThread.cpp:1234
#13 0xa45be3ac in NS_ProcessNextEvent (aThread=0x4, aMayWait=false) at /gecko/xpcom/threads/nsThreadUtils.cpp:513
#14 0xa4892920 in mozilla::ipc::MessagePump::Run (this=0xac066fa0, aDelegate=0xac01a0e0)
at /gecko/ipc/glue/MessagePump.cpp:87
#15 0xa4873392 in MessageLoop::RunInternal (this=0xdfa60e9) at /gecko/ipc/chromium/src/base/message_loop.cc:334
#16 MessageLoop::RunHandler (this=0xdfa60e9) at /gecko/ipc/chromium/src/base/message_loop.cc:327
#17 MessageLoop::Run (this=0xdfa60e9) at /gecko/ipc/chromium/src/base/message_loop.cc:309
---Type to continue, or q to quit---
#18 0xa5988c28 in nsBaseAppShell::Run (this=0xa0134700) at /gecko/widget/nsBaseAppShell.cpp:137
#19 0xa6087fa2 in nsAppStartup::Run (this=0xa013daf0) at /gecko/toolkit/components/startup/nsAppStartup.cpp:270
#20 0xa60e1270 in XREMain::XRE_mainRun (this=0xbea25464) at /gecko/toolkit/xre/nsAppRunner.cpp:4771
#21 XREMain::XRE_main (this=0xbea25464, argc=, argv=, aConfig=...)
at /gecko/toolkit/xre/nsAppRunner.cpp:4961
#22 0xa60e1dd6 in XRE_main (argc=234512617, argv=0x1, aConfig=...) at /gecko/toolkit/xre/nsAppRunner.cpp:5015
#23 0x87858456 in do_main (argc=1, argv=, envp=) at /gecko/b2g/app/nsBrowserApp.cpp:223
#24 main (argc=, argv=, envp=) at /gecko/b2g/app/nsBrowserApp.cpp:342

Comment 1

[Vincent Chang[:vchang][changyihsin]]

Attachment: Validate-pointer-before-dereference-it.patch

The patch fixed the crash.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Does this reproduce without using TaskTracer? My most recent understanding is that TaskTracer fundamentally breaks Gecko's thread prioritization/scheduling scheme, which could explain how the underlying invariant could be violated.

Assuming this does reproduce without TaskTracer, it would be great to have a test case that can reproduce this (possibly under chaos mode) or an rr/pernosco trace or some other build configuration that could shed more light on the situation leading up to this.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 9167798 [details] [diff] [review]
Validate-pointer-before-dereference-it.patch

Patches need to be submitted via Phabricator now. Please see https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch for documentation.

But note that this patch seems like a band-aid for a serious invariant violation and although it's possible such a check might be an appropriate fix in some cases, such a patch would want an in-depth justification for why this is an appropriate fix in the commit message and/or code changes, possibly citing a follow-up bug. For clarity I'm r-minusing and there's no need to upload this specific patch to phabricator.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Ah, the task-tracer related bug I was thinking of and the priorities issue is: https://bugzilla.mozilla.org/show_bug.cgi?id=1524594#c4

Comment 5

[Jens Stutte [:jstutte]]

Given that B2G is archived for a while now, should we really care here? Is there something more general here?

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jstutte, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Yeah, there's no potential for forward action here, especially since task tracer was known to drop runnable priorities at the time which could result in a reordering that would cause problems.