Does it have no HANDLE leak when transmitting HANDLE via IPC message?

[Leon]

From my understanding, in case of OS_POSIX, FileDescriptor is transmitted via IPC message attachment and it will be closed well whether sendmsg() succeeded or did not..

But for OS_WIN, HANDLE is treated as an int value to transmit, if sending failed or peer process failed to receive the message, won't it cause HANDLE leakage??

Thanks in advance.

[Mark Seaborn]

On 3 June 2015 at 04:54, Leon <leon...@intel.com> wrote:

From my understanding, in case of OS_POSIX, FileDescriptor is transmitted via IPC message attachment and it will be closed well whether sendmsg() succeeded or did not..

But for OS_WIN, HANDLE is treated as an int value to transmit, if sending failed or peer process failed to receive the message, won't it cause HANDLE leakage??

Yes, there would be a handle leak, in the receiver process.

There would also be a handle/FD leak if the sender side calls IPC::Get/TakeFileHandleForProcess() but then never sends the resulting handle/FD in an IPC message.  This can happen if the sender side starts preparing an IPC message to send but then gets an error part way through.  On Windows, this causes a handle leak in the receiver process.  On Unix, this causes an FD leak in the sender process (which would be worse than the leak on Windows if the sender is the browser process).

This issue came up recently.  One way to fix it would be to add a Windows equivalent of ParamTraits<base::FileDescriptor> that can send Windows handles.  I sketched out more details in this comment: https://codereview.chromium.org/1117883002/#msg12

Cheers,

Mark

[Leon]

Thank you very much for kindly explanation.

I'd like to go deep into this to see whether can I contribute something for it :)