Closed
Bug 1515938
Opened 6 years ago
Closed 2 years ago
Crash in nsObserverService::RemoveObserver
Categories
(Core :: WebVR, defect, P2)
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
=============================================================
Comment 1•6 years ago
|
||
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.
Comment 2•6 years ago
|
||
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.
Reporter | ||
Comment 3•6 years ago
|
||
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?
Reporter | ||
Comment 4•6 years ago
|
||
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?
Reporter | ||
Comment 5•6 years ago
|
||
(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.)
Comment 6•6 years ago
|
||
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.
Reporter | ||
Comment 7•6 years ago
|
||
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.)
Comment 8•6 years ago
|
||
This is a good chance that the fix to Bug 1460619 will also correct this.
Depends on: 1460619
Updated•5 years ago
|
Priority: -- → P2
Updated•2 years ago
|
Severity: critical → S2
Comment 9•2 years ago
|
||
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
Comment 10•2 years ago
|
||
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•