Closed Bug 1515938 Opened 5 years ago Closed 1 year ago

Crash in nsObserverService::RemoveObserver

Categories

(Core :: WebVR, defect, P2)

x86_64
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox66 --- disabled

People

(Reporter: jan, Unassigned)

References

Details

(Keywords: crash, nightly-community)

Crash Data

Debian Testing, gfx.webrender.all;true, layers.gpu-process.enabled;true, dom.vr.process.enabled;true

Opened https://www.rondomark.jp/ to reproduce bug 1515932. WebRender crashed (bp-17ad5ec6-16f3-4449-ac82-bd4a00181221) and this one too.

This might be a duplicate of bug 1513022.

This bug was filed from the Socorro interface and is
report bp-e22683cf-a70a-40f2-b82a-f3df80181221.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so nsObserverService::RemoveObserver xpcom/base/nsCOMPtr.h:512
1 libxul.so nsContentUtils::UnregisterShutdownObserver dom/base/nsContentUtils.cpp:4319
2 libxul.so mozilla::gfx::VRProcessManager::OnXPCOMShutdown gfx/vr/ipc/VRProcessManager.cpp:126
3 libxul.so mozilla::gfx::VRProcessManager::Observer::Observe gfx/vr/ipc/VRProcessManager.cpp:117
4 libxul.so nsObserverService::NotifyObservers xpcom/ds/nsObserverList.cpp:66
5 libxul.so mozilla::ShutdownXPCOM xpcom/build/XPCOMInit.cpp:805
6 libxul.so ScopedXPCOMStartup::~ScopedXPCOMStartup toolkit/xre/nsAppRunner.cpp:1323
7 libxul.so mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::reset mfbt/UniquePtr.h:486
8 libxul.so XREMain::XRE_main mfbt/UniquePtr.h:296
9 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp:4839

=============================================================
We are not interested in making "dom.vr.process.enabled;true" in Linux, and it is turned off by default. It will only be turned on in Windows at FF 66. I will submit a patch at Bug 1513022 to hide this preference to avoid users to turn it on. Besides, the crash callstack can't present the most cases, because the VR process code was landed in FF 64~65, it seems we have some reporters are happened before FF64.
For this crashes happen in Windows, we will fix it in Bug 1430040. Other crashes are happened in Android are not related with VR process.
I'm a total outsider and would like to ask a naive question:

(:kip (Kearwood Gilbert) from bug 1362578 comment 0)
> The Oculus and OpenVR runtime libraries require specific sandboxing rules.  We are working with external parties to determine what would needed to be whitelisted to allow access to VR hardware in a sandboxed process.  In order to allow the GPU process to have tighter sandboxing rules, we will move the VR hardware interfacing code (VRManager) to its own process.

As dom.vr.enabled is true on Linux,
1. would VR usually run in the GPU process if it gets enabled (layers.gpu-process.enabled;true)
2. and otherwise run in the parent process,
3. but both of these would have less restrictive sandboxing rules than the VR process on Windows? Or is VR security on Linux currently already as good as it would be with VR process on Windows?
Argh, I see, you need the VR process to have less restrictive sandboxing rules for it. So could VR prevent to make more restrictive sandboxing rules for the GPU process on Linux or are they already as good as they could be and VR would still work?
(Or does the GPU process on Linux doesn't have any sandboxing at all at the moment? I am just a profane Nightly user, sorry for asking.)
We only have GPU process in Windows and going to add sandbox level on the GPU process in Windows. The fundamental reason of implementing VR process is in order to make VR module still work even though GPU process turns on its sandbox.
Ah, good, thanks, that makes sense! :)
(Last bugs for the GPU process on X11/XWayland have recently been fixed (bug 1477037, bug 1415020). It's stable now and good to have for WebRender stability.)
Depends on: 1430040
Depends on: 1513022
This is a good chance that the fix to Bug 1460619 will also correct this.
Depends on: 1460619
Priority: -- → P2
Severity: critical → S2

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.