From e0852b35ab3f282760f6fae28dd49e8cd9bee19b Mon Sep 17 00:00:00 2001 From: Jed Davis Date: Tue, 16 Feb 2021 22:51:30 +0000 Subject: [PATCH] Bug 1692631 - Fix the profiler marker for IPC message reception on Windows. r=gerald This point in the code is the end of receiving a message, not the start (note the `if (partial) { break; }` above), so it should be marked accordingly. The profiler frontend is expecting the end marker; currently two of the four reported time intervals are `unknown` on Windows, and this patch fixes that. (Recording the receiving start time is complicated, because we don't have a `Messsage` object until we've read the buffer with the (end of the) header, and it might make more sense to timestamp it before the first receive operation. Currently, neither channel implementation attempts this.) Differential Revision: https://phabricator.services.mozilla.com/D105094 --- ipc/chromium/src/chrome/common/ipc_channel_win.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipc/chromium/src/chrome/common/ipc_channel_win.cc b/ipc/chromium/src/chrome/common/ipc_channel_win.cc index 5533cf787bc8..91bd33b6cb97 100644 --- a/ipc/chromium/src/chrome/common/ipc_channel_win.cc +++ b/ipc/chromium/src/chrome/common/ipc_channel_win.cc @@ -435,7 +435,7 @@ bool Channel::ChannelImpl::ProcessIncomingMessages( // has no routing ID), but we only emit a profiler marker for messages // with a routing ID, so there's no conflict here. AddIPCProfilerMarker(m, other_pid_, MessageDirection::eReceiving, - MessagePhase::TransferStart); + MessagePhase::TransferEnd); #ifdef IPC_MESSAGE_DEBUG_EXTRA DLOG(INFO) << "received message on channel @" << this << " with type "