1490777 - Silence warning in IDMap::Remove during fuzzing

Status: RESOLVED FIXED

(Core :: IPC, enhancement, P1)

Description

[Alex Gaynor [:Alex_Gaynor]]

In IPC fuzzing it's possible to reach this warning. It can basically flood the output, so we should silence this -- or make it an error so we can figure out why it's happening :-)

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I did a little looking around in searchfox, and it's not immediately obvious why this would happen.

For example, ToplevelState::ShmemDestroyed doesn't call Remove unless the shmem ID is mapped: https://searchfox.org/mozilla-central/rev/de7676288a78b70d2b9927c79493adbf294faad5/ipc/glue/ProtocolUtils.cpp#970

The other uses I can find require having an object deserialized from the ID, which should also require that the ID was mapped.


It might be informative to change the warning to an assertion and get a stack (or an rr trace).

Comment 2

[Alex Gaynor [:Alex_Gaynor]]

Sounds good -- I'll give this a spin with an assert and see if we can figure it out.

Comment 3

[Alex Gaynor [:Alex_Gaynor]]

Ok, what's actually happening here is that in the Shmem support for the IPC fuzzer we add/remove shmems from the protocol. If the shmem was removed by the IPC message, then we'll hit this warning.

Comment 4

[Alex Gaynor [:Alex_Gaynor]]

Attachment: Bug 1490777 -- don't log a warning in IPC fuzzing if a shmem segment was removed; r?posidron

Comment 5

[Christoph Diehl [:posidron]]

Comment on attachment 9009243 [details]
Bug 1490777 -- don't log a warning in IPC fuzzing if a shmem segment was removed; r?posidron

Christoph Diehl [:posidron] has approved the revision.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/84ad3a2b20d0
don't log a warning in IPC fuzzing if a shmem segment was removed; r=posidron

Comment 7

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/84ad3a2b20d0