Bugzilla

For what it's worth, here are the symbolized stacks explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

Edit: For more clarity, this should probably read as *something like*: there are two processes or threads that register themselves as consumers for these surfaces, but only one of them was able to run the code that triggers `ObserveSharedSurfaceRelease`.

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

Edit: For more clarity, this should probably read as something like: we added 3650 entries, for which, out of the two "things" (threads? processes?) that registered additional consumers for them, only one has (so far) executed the code path to unregister those consumers through `ObserveSharedSurfaceRelease`.

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

Edit: For more clarity, this should probably read as something like: we added 3650 entries, for which, out of the two "things" (threads? processes?) that registered additional consumers for them, only one has executed the code path to unregister those consumers through `ObserveSharedSurfaceRelease`.

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

Edit: For more clarity, this should probably read as something like: we added 3650 surfaces, for which, out of the two "things" (threads? processes?) that registered additional consumers for them, only one has successfully executed the code path to unregister those consumers through `ObserveSharedSurfaceRelease`, hence the underlying textures have not been released (yet).

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

Edit: For more clarity, this should probably read as something like: we added 3650 surfaces, for which, out of the two "things" (threads? processes?) that registered additional consumers for them, only one has successfully executed the code path to unregister those consumers through `ObserveSharedSurfaceRelease`, hence the underlying textures have not been released.

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330).

Edit: For more clarity, this should probably read as something like: we added 3650 surfaces, for which, out of the two "things" (threads? processes?) that registered additional consumers for them, only one has successfully executed the code path to unregister those consumers through `ObserveSharedSurfaceRelease`, hence the underlying textures for these surfaces have not been released.

For what it's worth, here are the symbolized stacks from comment 55 explaining why these surfaces are still alive. It seems that only half of the calls to add consumers originating from `WebRenderBridgeParent::RecvUpdateResources` have a matching call to `mozilla::layers::WebRenderBridgeParent::ObserveSharedSurfaceRelease`. Note that there are two stacks for `WebRenderBridgeParent::RecvUpdateResources`: one going through [this path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#300) and the other through [that path](https://searchfox.org/mozilla-central/source/ipc/glue/MessagePump.cpp#330), so the total number of calls is the sum of the two paths.

Edit: For more clarity, this should probably read as something like: we added 3650 surfaces, for which, out of the two "things" (threads? processes?) that registered additional consumers for them, only one has successfully executed the code path to unregister those consumers through `ObserveSharedSurfaceRelease`, hence the underlying textures for these surfaces have not been released.