Looks like we have another instance of this. Poking a bit more: - `DeleteTask<IPC::Channel>::Run()` is what is freeing our channel underneath us. - [`Transport` is a typedef of `IPC::Channel`](https://searchfox.org/mozilla-central/rev/883bfd385efc917d5e787ba66fb51824f6f0e3d6/ipc/glue/Transport.h#25) - [There's one instance I see of `DeleteTask<Transport>`](https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/ipc/glue/ProtocolUtils.cpp#676) and none for `Channel`. So the IPC::Channel/Transport is being set up for deletion by `~IToplevelProtocol()`. It looks like this same channel is then
Bug 1557739 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looks like we have another instance of this. Poking a bit more: - `DeleteTask<IPC::Channel>::Run()` is what is freeing our channel underneath us. - [`Transport` is a typedef of `IPC::Channel`](https://searchfox.org/mozilla-central/rev/883bfd385efc917d5e787ba66fb51824f6f0e3d6/ipc/glue/Transport.h#25) - [There's one instance I see of `DeleteTask<Transport>`](https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/ipc/glue/ProtocolUtils.cpp#676) and none for `Channel`. Edit: didn't mean to post this quite so soon, still investigating, will add more in further edits.
Looks like we have another instance of this. Poking a bit more: - `DeleteTask<IPC::Channel>::Run()` is what is freeing our channel underneath us. - [`Transport` is a typedef of `IPC::Channel`](https://searchfox.org/mozilla-central/rev/883bfd385efc917d5e787ba66fb51824f6f0e3d6/ipc/glue/Transport.h#25) - [There's one instance I see of `DeleteTask<Transport>`](https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/ipc/glue/ProtocolUtils.cpp#676) and none for `Channel`. So the IPC::Channel/Transport is being set up for deletion by `~IToplevelProtocol()`. Then later during `~IToplevelProtocol()` we try and touch the now deleted memory. It's not clear to me if this is a race in a single call to `~IToplevelProtocol()`, or if we have multiple different top level protocols clobbering one another. The ownership appears to be that `ITopLevelProtocol` owns a [`MessageChannel`](https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/ipc/glue/ProtocolUtils.h#577) and `MessageChannel` has a [`MessageLink`](https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/ipc/glue/MessageChannel.h#616). It looks like if we have a `ProcessLink` subclass of `MessageLink` it also has a [`Transport`](https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/ipc/glue/MessageLink.h#99). In this case when we call `MessageChannel::Clear` (frame #2 on our crashing stack) it calls through to [here](https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/ipc/glue/MessageLink.cpp#369), which is interacting with what seems likely to be the freed transport. It's still not clear to me what is allocating and setting up all these transports, so will keep looking at that.