wiki:Debugging With Visual Studio

Version 9 (modified by Brian Burg, 6 years ago) (diff)

restructure sections into wk1/wk2/test runners/misc.

Debugging WebKit

  1. Open Source/WebKit/WebKit.vcxproj/WebKit.sln using Visual Studio 2013 or Visual Studio Express (Desktop) 2013 or later.

If you get errors about not being able to find .props files, run Tools/Scripts/update-webkit, then close and relaunch Cygwin and Visual Studio or Visual Studio Express.

  1. Set WinLauncher as the solution's StartUp project.

Select the WinLauncher project in the Solution Explorer, then choose Project > Set as StartUp Project. This will cause the project to turn bold in the Solution Explorer.

  1. Launch the debugger

Choose Debug > Start Debugging.

Debugging DumpRenderTree

  1. Set DumpRenderTreeLauncher as your startup project.
  1. Set the layout test as a command argument.

In DumpRenderTreeLauncher's properties, go to Configuration Properties > Debugging and set the Command Arguments field to the full path of the layout test you want to debug.

  1. Launch the debugger.

Debugging WebKit2 / WebKitTestRunner

You can attach a single debugger to more than one process. To do this, launch or attach to the first process, then use Tools > Attach to Process… or Ctrl+Alt+P to attach to the second process. Your breakpoints will apply to both processes.

There are two ways to see which process the debugger is currently operating on, and to switch the current process: the Processes window and the Debug Location toolbar. You can open the Processes window using Debug > Windows > Processes or Ctrl+Shift+Alt+P. You can show the Debug Location toolbar using View > Toolbars > Debug Location.

Visual Studio will always pause all processes (i.e., you can't pause just one process). Similarly, Visual Studio will always step all processes when using the Step In/Over/Out commands.

Miscellaneous Tips

Using the Microsoft and Safari Symbol Servers

Follow the instructions for using the Microsoft and Safari symbol servers so that Visual Studio can show you backtraces that involve closed-source components.

Using Watch Window

You can open any of the Watch windows using the Debug > Windows > Watch submenu.

MSDN Magazine published a very useful article about Watch window pseudo-variables and format specifiers. Those of particular interest to WebKit developers are mentioned explicitly below, but the whole article is worth a read.

  • Adding $err,hr to the Watch Window will show you what ::GetLastError() would return at this moment, and will show you both the numerical error value and the error string associated with it.

Calling CFShow

When debugging code that uses CF types, you can invoke the CFShow function in the Immediate window (Debug > Windows > Immediate or Ctrl+Alt+I) to print a debug description of a CF object to the Output window like so:

{,,CoreFoundation}CFShow((void*)0x12345678)

Note that you usually won't be able to pass a variable name as the parameter to CFShow, as the Immediate window will get confused and think you're specifying a symbol in CoreFoundation.dll rather than whatever code you're debugging. It's usually easiest just to pass the address of the object directly as above.

Inspecting WebKit2 API types

You can inspect WebKit2 API types in Visual Studio by casting them to their underlying WebKit2 implementation type. For example, say you have a WKMutableDictionaryRef that points to address 0x12345678 and want to see what it contains. You can view its contents using the following watch expression (in either the Watch Window or Quick Watch Window):

{,,WebKit}(WebKit::MutableDictionary*)0x12345678

The same technique will work for other WebKit2 API types as long as you substitute the appropriate type for MutableDictionary above.