1569725 - Crash in [@ JS::OwningCompileOptions::element]

Status: RESOLVED FIXED

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

Description

[Marcia Knous [:marcia]]

This bug is for crash report bp-6b92292d-1ca1-4cc4-a7dd-f719b0190728.

11 Windows crashes/8 installations, starting in build id 20190727093108 - https://bit.ly/2Ydd8ZL.

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9813549331af43eaebc60e0114458c12533431b5&tochange=1416771db267f77fa6bd28b2eaa214a706427f55

Some compile related things landing in Bug 1567388, maybe :jandem can help here.

Top 10 frames of crashing thread:

0 xul.dll JS::OwningCompileOptions::element js/public/CompileOptions.h:257
1 xul.dll bool mozilla::dom::CheckLoadRunnable::MainThreadRun dom/notification/Notification.cpp:2204
2 xul.dll mozilla::dom::WorkerMainThreadRunnable::Run dom/workers/WorkerRunnable.cpp:569
3 xul.dll void mozilla::ThrottledEventQueue::Inner::ExecuteRunnable xpcom/threads/ThrottledEventQueue.cpp:252
4 xul.dll nsresult mozilla::ThrottledEventQueue::Inner::Executor::Run xpcom/threads/ThrottledEventQueue.cpp:80
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1224
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:88
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290

Comment 1

[Jan de Mooij [:jandem]]

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #0)

Some compile related things landing in Bug 1567388, maybe :jandem can help here.

Different kind of compile :)

However, looking at that regression range + stack, I don't trust the OwningCompileOptions::element frame much. Maybe it got merged with an identical function or there was vtable corruption.

I do see some service worker registration changes in that range that look suspicious considering registration->GetActive() is crashing, so CC'ing Perry.

Comment 2

[Jan de Mooij [:jandem]]

Oh and the crash address is 0x78, suggesting registration is nullptr and we crash while loading its mActiveWorker field. I didn't verify the offsets but it would make sense.

Comment 3

[Perry Jiang [:perry] [no longer employee, use ni?]]

Yeah it looks like registration is nullptr. I'll have a fix incoming.

Comment 4

[Perry Jiang [:perry] [no longer employee, use ni?]]

Attachment: Bug 1569725 - Check for active Service Worker with ServiceWorkerRegistrationDescriptor r=asuth

The previous implementation checked for a registration's active worker on the
main thread using ServiceWorkerManager::GetRegistration. This has two
problems:

• ServiceWorkerManager can't be relied upon in parent-intercept mode, and
• SWM:GetRegistration won't return the registration if .unregister() has
  been called.

We can perform the same checks without using the SWM by using
ServiceWorkerRegistrationDescriptor, and this also allows us to bypass using a
worker -> main thread sync runnable.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/31868b52d8ad
Check for active Service Worker with ServiceWorkerRegistrationDescriptor r=asuth

Comment 6

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/31868b52d8ad