content/common/memory_benchmark_messages.h - Issue 15082004: Adds chrome.memoryBenchmarking.heapProfilerDump for the browser process.

Side by Side Diff: content/common/memory_benchmark_messages.h

Issue 15082004: Adds chrome.memoryBenchmarking.heapProfilerDump for the browser process. (Closed) Base URL: http://git.chromium.org/chromium/src.git@master

Patch Set: Patch Created 7 years, 7 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 // Copyright (c) 2013 The Chromium Authors. All rights reserved.	1 // Copyright (c) 2013 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

	5 // IPC messages for device motion.
	piman 2013/05/10 18:13:52 nit: fix description. nit: fix description. bulach 2013/05/10 18:46:03 Done. Show quoted text On 2013/05/10 18:13:52, piman wrote: > nit: fix description. Done.
5 // Multiply-included message file, hence no include guard.	6 // Multiply-included message file, hence no include guard.

6	7

7 #include "content/public/common/password_form.h"	8 #include <string>

	9

8 #include "ipc/ipc_message_macros.h"	10 #include "ipc/ipc_message_macros.h"

9	11

10 #define IPC_MESSAGE_START OneClickSigninMsgStart	12 #define IPC_MESSAGE_START MemoryBenchmarkMsgStart

11	13

12 IPC_MESSAGE_ROUTED1(OneClickSigninHostMsg_FormSubmitted, content::PasswordForm)	14 IPC_SYNC_MESSAGE_ROUTED0_1(MemoryBenchmarkHostMsg_HeapProfilerDump,
	piman 2013/05/10 18:13:52 This message doesn't need to be ROUTED, it could j This message doesn't need to be ROUTED, it could just be CONTROL. That way you don't need to find the right view in HeapProfilerDumpBrowser, you can directly go to RenderThreadImpl::current()->Send() bulach 2013/05/10 18:46:03 ah, right.. much simpler, thanks! Show quoted text On 2013/05/10 18:13:52, piman wrote: > This message doesn't need to be ROUTED, it could just be CONTROL. That way you > don't need to find the right view in HeapProfilerDumpBrowser, you can directly > go to RenderThreadImpl::current()->Send() ah, right.. much simpler, thanks!
	15 std::string /* dump file name */)
	piman 2013/05/10 18:13:52 nit: use FilePath in IPCs. nit: use FilePath in IPCs. palmer 2013/05/10 18:42:17 It's more than a nit. :) An arbitrary file pathnam Show quoted text > nit: use FilePath in IPCs. It's more than a nit. :) An arbitrary file pathname write IPC, for memory benchmarking, cost us a Pwnium loss last year. The correct pattern is: client process asks browser process for a file descriptor/HANDLE to write to; browser chooses a pathname statically or otherwise safely; browser opens it with correct flags; browser sends FD back to client. (Options: The client can close the FD when done; or the client can send a message to the browser when it's time to close it and the browser actually calls close; or the browser can unilaterally close it at a time of its choosing.) Should this be guarded on #if defined(HAS_MEMORY_BENCHMARK) ? Part of the previous bug was that the IPC endpoint was present, even though no callers remained in a Release build. bulach 2013/05/10 18:46:03 Done. Show quoted text On 2013/05/10 18:13:52, piman wrote: > nit: use FilePath in IPCs. Done. bulach 2013/05/10 18:47:31 sorry, I didn't address this comment in patchset # Show quoted text On 2013/05/10 18:42:17, Chromium Palmer wrote: > > nit: use FilePath in IPCs. > > It's more than a nit. :) An arbitrary file pathname write IPC, for memory > benchmarking, cost us a Pwnium loss last year. > > The correct pattern is: client process asks browser process for a file > descriptor/HANDLE to write to; browser chooses a pathname statically or > otherwise safely; browser opens it with correct flags; browser sends FD back to > client. > > (Options: The client can close the FD when done; or the client can send a > message to the browser when it's time to close it and the browser actually calls > close; or the browser can unilaterally close it at a time of its choosing.) > > Should this be guarded on #if defined(HAS_MEMORY_BENCHMARK) ? Part of the > previous bug was that the IPC endpoint was present, even though no callers > remained in a Release build. sorry, I didn't address this comment in patchset #2, let me address this now...
OLD	NEW

« content/browser/renderer_host/memory_benchmark_message_filter.cc ('K') | « content/common/content_message_generator.h ('k') | content/content_browser.gypi » ('j') | no next file with comments »