1659704 - Crash in [@ std::__ndk1::__tree<T>::find<T>]

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[Ryan VanderMeulen [:RyanVM]]

This bug is for crash report bp-d34ecfab-599e-440d-8d6b-ee3fd0200818.

This is showing up as a new signature with the Focus 8.6 release based on Gecko 79. Looks like it affects Fenix also.

Top 10 frames of crashing thread:

0 libxul.so std::__ndk1::__tree_iterator<std::__ndk1::__value_type<mozilla::layers::LayersId, mozilla::layers::CompositorBridgeParent::LayerTreeState>, std::__ndk1::__tree_node<std::__ndk1::__value_type<mozilla::layers::LayersId, mozilla::layers::CompositorBridgeParent::LayerTreeState>, void*>*, long> std::__ndk1::__tree<std::__ndk1::__value_type<mozilla::layers::LayersId, mozilla::layers::CompositorBridgeParent::LayerTreeState>, std::__ndk1::__map_value_compare<mozilla::layers::LayersId, std::__ndk1::__value_type<mozilla::layers::LayersId, mozilla::layers::CompositorBridgeParent::LayerTreeState>, std::__ndk1::less<mozilla::layers::LayersId>, true>, std::__ndk1::allocator<std::__ndk1::__value_type<mozilla::layers::LayersId, mozilla::layers::CompositorBridgeParent::LayerTreeState> > >::find<mozilla::layers::LayersId> /builds/worker/fetches/android-ndk/sources/cxx-stl/llvm-libc++/include/__tree:2598
1 libxul.so mozilla::layers::GetStateForRoot gfx/layers/ipc/CompositorBridgeParent.cpp:2459
2 libxul.so mozilla::layers::CompositorBridgeParent::GetGeckoContentControllerForRoot gfx/layers/ipc/CompositorBridgeParent.cpp:2494
3 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:244
4 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:247
5 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:247
6 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:247
7 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:247
8 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:247
9 libxul.so mozilla::layers::RemoteContentController::UpdateOverscrollVelocity gfx/layers/ipc/RemoteContentController.cpp:247

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Regression from bug 1536833 maybe?

Comment 2

[Nicolas Silva [:nical]]

The stacks are recursing into UpdateOverscrollVelocity quite deep, perhpas we are accidentally going in a circle and recursing forever until running out of stack?

Comment 3

[Botond Ballo [:botond]]

The crash stack suggests that in this call, rootController is also a RemoteContentController and so we get into an infinite recursion. The code assumes it will be a ChromeProcessController.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Yeah that's what it seems like. It's pretty weird because it means the root CompositorBridgeParent has a RemoteContentController as its GeckoContentController implementation, which should only happen if the GPU process is enabled, which should never be the case on Android. And even if it were, the XRE_IsParentProcess() check here should catch that.

I looked at some of the other codepaths too and don't see how this can be happening. Maybe we should land more MOZ_RELEASE_ASSERTs to isolate the problem.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

If somehow we're getting a BrowserChild instance created in the parent process, and it runs this code that will trigger this code on the root CBP which could then cause this crash on the next overscroll.

I'm not sure why a BrowserChild instance might get created in the parent process, maybe extensions or something? It might also be something else entirely but of the codepaths I've seen this seems the most plausible.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

:nika said that we should never be getting a BrowserChild instance in the parent process. So I'm not sure what's going on here. I have a patch that asserts things harder. https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=072f08ca10adbca2a03a494d565b374d98f99306

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1659704 - Add some release assertions to find out why assumptions are breaking. r?botond,snorp

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3f301e1e3b7c
Add some release assertions to find out why assumptions are breaking. r=snorp

Comment 9

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/3f301e1e3b7c

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Should this have been closed yet?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

We'll probably see the crash disappear and be replaced with another one on one of the release asserts. So the signature will change, might as well keep this one closed for now.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Alright, thanks. We'll keep an eye on the incoming reports from Nightly (keeping in mind that there's a bit of lag with Fenix Nightly builds picking up newer GV builds).