Bug 1514417 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
We can reproduce this on Windows 64-bit optimization release build. It doesn't matter if we disable ANGLE, or enable VR process and dom.vr.external. I think it is caused by the deadlock issue between VRService thread and VR_SubmitFrame thread when both of them wanna access mAPIShmem. VR_SubmitFrame is writing to mExternalShmem->browserState at [1], and VRService thread is reading mAPIShmem at [2]. So, the browserGenerationA will be not equal to browserGenerationB when happening the deadlock, then it makes this loop block [3]. 


[1] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#848
[2] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/service/VRService.cpp#464
[3] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#275
Revision 1 by
on 
We can reproduce this on Windows 64-bit optimization release build. It doesn't matter if we disable ANGLE, or enable VR process and dom.vr.external. I think it is caused by the deadlock issue between VRService thread and VR_SubmitFrame thread when both of them wanna access mAPIShmem. It is because VR_SubmitFrame is writing to mExternalShmem->browserState at [1], and VRService thread is reading mAPIShmem at [2] simultaneously. So, the browserGenerationA will be not equal to browserGenerationB when happening the deadlock, then it makes this loop block [3]. 


[1] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#848
[2] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/service/VRService.cpp#464
[3] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#275
Revision 2 by
on 
We can reproduce this on Windows 64-bit optimization release build. It doesn't matter if we disable ANGLE, or enable VR process and dom.vr.external. I think it is caused by the deadlock issue between VRService thread and VR_SubmitFrame thread when both of them wanna access mAPIShmem. It is because VR_SubmitFrame is writing to mExternalShmem->browserState at [1], and VRService thread is reading mAPIShmem at [2] simultaneously. So, the browserGenerationA will not be equal to browserGenerationB when happening the deadlock, then it makes this loop block [3]. 


[1] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#848
[2] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/service/VRService.cpp#464
[3] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#275
Revision 3 by
on 
We can reproduce this on Windows 64-bit optimization release build. It doesn't matter if we disable ANGLE, or enable VR process and dom.vr.external. I think it is caused by the deadlock issue between VRService thread and VR_SubmitFrame thread when both of them wanna access mAPIShmem. It is because VR_SubmitFrame is writing to mExternalShmem->browserState at [1], and VRService thread is reading mAPIShmem at [2] simultaneously. So, the browserGenerationA will not be equal to browserGenerationB when happening this deadlock, then it makes this loop block [3]. 


[1] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#848
[2] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/service/VRService.cpp#464
[3] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#275
Revision 4 by
on 
We can reproduce this on Windows 64-bit optimization release build. It doesn't matter if we disable ANGLE, or enable VR process and dom.vr.external. I think it is caused by the deadlock issue between VRService thread and VR_SubmitFrame thread when both of them wanna access mAPIShmem. It is because VR_SubmitFrame is writing to mExternalShmem->browserState at [1], and VRService thread is reading mAPIShmem at [2] simultaneously. So, the browserGenerationA will not be equal to browserGenerationB when happening this deadlock, then it blocks this loop[3]. 


[1] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#848
[2] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/service/VRService.cpp#464
[3] https://searchfox.org/mozilla-central/rev/c035ee7d3a5cd6913e7143e1bce549ffb4a566ff/gfx/vr/gfxVRExternal.cpp#275

Back to Bug 1514417 Comment 13