1267326 - Use UniquePtr with IPC::Message more

Status: RESOLVED INCOMPLETE

(Core :: IPC, defect, P3)

Description

[Andrew McCreight [:mccr8]]

There's a bunch of places where raw pointers to IPC::Message are passed around, including in IPDL-generated code. UniquePtr would be better, because it would be easier to figure out what is going on, and we've had leaks in the past due to not cleaning things up properly on error paths.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: Use UniquePtr more in IPC code. WIP

This patch kind of spiralled out of control, and it is only lightly tested.

Comment 2

[Andrew McCreight [:mccr8]]

With this patch, the IPDL generated code for Send methods looks like:

    mozilla::UniquePtr<IPC::Message> msg__ = PContent::Msg_PBrowserConstructor(MSG_ROUTING_CONTROL);

    Write(actor, (msg__).get(), false);
    Write(tabId, (msg__).get());

    [...]

    bool sendok__ = (mChannel).Send(mozilla::Move(msg__));

I suppose I should change the Write() methods to take const UniquePtr<Message>&. (I was using the last paragraph of the comment on UniquePtr to decide what types to use.)

Comment 3

[Andrew McCreight [:mccr8]]

This is green on L64 debug at least:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=35c404513bf7

One sketchy part is where I call into OnMessageReceivedFromLink() with a UniquePtr, such as in ThreadLink::EchoMessage():
  mChan->OnMessageReceivedFromLink(Move(*aMsg));

I also would like to figure out how to split this up a bit. The patch also needs various cleaning up, like using mozilla:: where it isn't actually needed.

Comment 4

[Andrew McCreight [:mccr8]]

I think some work has been done on this in the interim. I'm sure there's more to do, but we might as well file a new bug at this point.