[Chrome源码阅读] Chrome的多进程调试方法

Chrome的多进程模型给DEBUG带来了很大的挑战。这篇文章尝试着解释如何在VS中调试Chrome的子进程。

如果你设置代码的断点，默认情况下，VS只会跟踪那些在主进程Browser代码中的那些断点。VS提供了"Attach To Process"的方法。比如当Render Process启动之后，可以用菜单"Debug"=>"Attach To Process"选项，选择那个新产生的进程，然后在你需要跟踪的代码处设置断点，就可以。但是这种方法，只能在子进程启动之后，才比较有效，如果我们想在子进程启动时，跟踪某些代码的执行，就没有办法了。

针对这个Chrome从源代码级别提供了支持。共有两种方法：

1. 用启动选项“--single-process“，以单进程的方法来启动Chrome。这样当然可以跟踪那些原本在子进程里面的代码了。呵呵。

2. 用启动选项"--renderer-startup-dialog"和"--no-sandbox"。两个选项将会让子进程在启动之后，弹出一个模态对话框。之后在关闭这个对话框之后才可以继续运行代码。在这期间，我们可以用上述"Attach To Process"的方法来跟踪子进程代码的执行。

之所以要加上"--no-sandbox"，是因为默认情况下Chrome的子进程的创建和启动是在sanbox中(也就说访问系统资源是严格限制的)，无法显示模态对话框UI。

Render进程的主函数如下：

int RendererMain(const MainFunctionParams& parameters) {
const CommandLine& parsed_command_line = parameters.command_line_;
base::ScopedNSAutoreleasePool* pool = parameters.autorelease_pool_;

// This function allows pausing execution using the --renderer-startup-dialog
// flag allowing us to attach a debugger.
// Do not move this function down since that would mean we can't easily debug
// whatever occurs before it.
HandleRendererErrorTestParameters(parsed_command_line);

HandleRenderErrorTestParameters函数会显示这个模态对话框。

// This function provides some ways to test crash and assertion handling
// behavior of the renderer.
static void HandleRendererErrorTestParameters(const CommandLine& command_line) {
// This parameter causes an assertion.
if (command_line.HasSwitch(switches::kRendererAssertTest)) {
DCHECK(false);
}

// This parameter causes a null pointer crash (crash reporter trigger).
if (command_line.HasSwitch(switches::kRendererCrashTest)) {
int* bad_pointer = NULL;
*bad_pointer = 0;
}

if (command_line.HasSwitch(switches::kRendererStartupDialog)) {
#if defined(OS_WIN)
std::wstring title = l10n_util::GetString(IDS_PRODUCT_NAME);
title += L" renderer";  // makes attaching to process easier
::MessageBox(NULL, L"renderer starting...", title.c_str(),
MB_OK | MB_SETFOREGROUND);
#elif defined(OS_LINUX)