First see get the code for checkout and build instructions. Getting startedYou can use Visual Studio's built-in debugger or WinDBG to debug Chromium. You don't need to use the IDE to build in order to use the debugger: Ninja is used to build Chromium and most developers invoke it from a command prompt, and then open the IDE for debugging as necessary. To start debugging an executable from the command line:
Note that the path to the binary must use backslashes and must include the ".exe" suffix or Visual Studio will open and do nothing. Note also that this assumes you have Visual Studio installed and have devenv.exe on your path. You can open a Visual Studio developer command prompt or run this command to add it to your path:
Visual Studio 2017 is not recommended for debugging of Chromium - use a newer version for best performance and stability.
symbol_level=2 is the default on Windows and gives full debugging information with types, locals, globals, function names, and source/line information. symbol_level=1 creates smaller PDBs with just function names, and source/line information - source-level debugging is still supported (new from June 2019).
ProfilesIt's a good idea to use a different Chrome profile for your debugging. If you are debugging Google Chrome branded builds, or use a Chromium build as your primary browser, the profiles can collide so you can't run both at once, and your stable browser might see profile versions from the future (Google Chrome and Chromium use different profile directories by default so won't collide). Use the command-line option:
Using the IDE, go to the Debugging tab of the properties of the chrome project, and set the Command Arguments.
Chrome debug logEnable Chrome debug logging to a file by passing --enable-logging --v=1 command-line flags at startup. Debug builds place the chrome_debug.log file in the out\Debug directory. Release builds place the file in the top level of the user data Chromium app directory, which is OS-version-dependent. For more information, see logging and user data directory details.
Symbol serverIf you are debugging official Google Chrome release builds, use the symbol server:
In Visual Studio, this goes in Tools > Options under Debugging > Symbols. You should set up a local cache in a empty directory on your computer. In windbg you can add this to your symbol server search path with the command below, where c:\Symbols is a local cache directory:
Alternately, You can set the _NT_SYMBOL_PATH environment variable to include both the Microsoft and Google symbol servers - VS, windbg, and other tools should both respect this environment variable:
Note that symbol servers will let the debuggers download both the PE files (DLLs and EXEs) and the PDB files. Chrome often loads third party libraries and partial symbols for some of these are also public. For example: AMD: https://download.amd.com/dir/bin Nvidia: https://driver-symbols.nvidia.com/ Intel: https://software.intel.com/sites/downloads/symbols/ For example, for completeness, the following symbol server environment variable will resolve all of the above sources - but this is more than is normally needed:
You should set up source indexing in your debugger (.srcfix in windbg, Tools-> Options-> Debugging-> General-> Enable source server support in Visual Studio) so that the correct source files will automatically be downloaded based on information in the downloaded symbols. This is highly recommended when debugging released Google Chrome builds or looking at crash dumps. Having the correct version of the source files automatically show up saves significant time so you should definitely set this.
Multi-process issuesChromium can be challenging to debug because of its multi-process architecture. When you select Run in the debugger, only the main browser process will be debugged. The code that actually renders web pages (the Renderer) and the plugins will be in separate processes that's not (yet!) being debugged. The ProcessExplorer tool has a process tree view where you can see how these processes are related. You can also get the process IDs associated with each tab from the Chrome Task Manager (right-click on an empty area of the window title bar to open). Automatically attach to child processes There are two Visual Studio extensions that enable the debugger to automatically attach to all Chrome processes, so you can debug all of Chrome at once. Microsoft's Child Process Debugging Power Tool is a standalone extension for this, and VsChromium is another option that bundles many other additional features. In addition to installing one of these extensions, you must run Visual Studio as Administrator, or it will silently fail to attach to some of Chrome's child processes. Single-process modeOne way to debug issues is to run Chromium in single-process mode. This will allow you to see the entire state of the program without extra work (although it will still have many threads). To use single-process mode, add the command-line flag
This approach isn't perfect because some problems won't manifest themselves in this mode and some features don't work and worker threads are still spawned into new processes. Manually attaching to a child process
You can attach to the running child processes with the debugger. Select Tools > Attach to Process and click the chrome.exe process you want to attach to. Before attaching, make sure you have selected only Native code when attaching to the process This is done by clicking Select... in the Attach to Process window and only checking Native. If you forget this, it may attempt to attach in "WebKit" mode to debug JavaScript, and you'll get an error message "An operation is not legal in the current state." You can now debug the two processes as if they were one. When you are debugging multiple processes, open the Debug > Windows > Processes window to switch between them. Sometimes you are debugging something that only happens on startup, and want to see the child process as soon as it starts. Use:
--renderer-startup-dialog --no-sandbox
You have to disable the sandbox or the dialog box will be prohibited from showing. When the dialog appears, visit Tools > Attach to Process and attach to the process showing the Renderer startup dialog. Now you're debugging in the renderer and can continue execution by pressing OK in the dialog.
Startup dialogs also exist for other child process types: --gpu-startup-dialog, --ppapi-startup-dialog, --plugin-startup-dialog (for NPAPI).
You can also try the vs-chromium plug-in to attach to the right processes.
Semi-automatically attaching the debugger to child processes
The following flags cause child processes to wait for 60 seconds in a busy loop for a debugger to attach to the process. Once either condition is true, it continues on; no exception is thrown.
--wait-for-debugger-children[=filter]The filter, if provided, will fire only if it matches the --type parameter to the process. Values include renderer, plugin (for NPAPI), ppapi, gpu-process, and utility. When using this option, it may be helpful to limit the number of renderer processes spawned, using: Image File Execution OptionsUsing Image File Execution Options (IFEO) will not work because CreateProcess() returns the handle to the debugger process instead of the intended child process. There are also issues with the sandbox. You can do time travel debugging using WinDbg Preview (can be installed from the Microsoft Store). This lets you execute a program forward and backwards. This is especially useful when setting data breakpoints (ba command) and reverse continuing, so you can see when a certain variable was last changed to its current value. You can install JsDbg as a plugin for WinDbg or Visual Studio. It interactively lets you look at data structures (such as the DOM tree, Accessibility tree, layout object tree, and others) in a web browser as you debug. See the JsDbg site for some screen shots and usage examples. This also works when examining memory dumps (though not minidumps), and also works together with time travel debugging. Visual Studio hintsDebug visualizersChrome's custom debug visualizers should be added to the pdb files and automatically picked up by Visual Studio. The definitions are in //tools/win/DebugVisualizers if you need to modify them (the BUILD.gn file there has additional instructions). Don't step into trivial functions
|
For Developers > How-Tos >
