How to Build Google Crashpad

Overview

Crashpad is a cross-platform system for end-to-end crash reporting. Crashpad supports reporting of native crashes on a variety of operating systems including Windows, macOS, Linux, Android, and iOS. Crashpad also provides tools such as dump_syms, symupload and minidump_stackwalk that provide developers with function names, file names, and line numbers in their crash reports. Integrating with Crashpad helps software engineers find and fix program crashes in order to develop more stable applications.

Installing depot_tools

The Chromium depot_tools are a set of tools that are required to build Crashpad. The documentation claims that Python 2.7 is a requirement for depot_tools, however since checking out Crashpad uses only a subset of the depot tools Python 3+ worked fine for BugSplat.
Run the following terminal commands below to clone depot_tools and add the tools to your system PATH variable. Be sure to change /path/to/depot_tools to the path where you cloned depot_tools.

macOS

1
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
2
sudo echo "export PATH=/path/to/depot_tools:$PATH" >> ~/.zshrc
Copied!

Linux

1
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
2
sudo echo "export PATH=/path/to/depot_tools:$PATH" >> ~/.bashrc
Copied!

Windows

1
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
2
setx path "%path%;C:\path\to\depot_tools"
Copied!

Getting the Crashpad Source

The Crashpad source code can be found here. Crashpad’s dependencies are managed by gclient instead of git submodules, so it is best to use fetch to get the source code.

Initial Checkout

1
mkdir ~/crashpad
2
cd ~/crashpad
3
fetch crashpad
Copied!

Subsequent Checkouts

1
cd ~/crashpad/crashpad
2
git pull -r
3
gclient sync
Copied!

Building Crashpad

Crashpad uses gn to generate ninja build files.
By default gn generates a configuration for building static libraries. If you would like to build dynamic libraries see this post on Stack Overflow.

Generating Build Configuration

1
cd ~/crashpad/crashpad
2
gn gen out/Default
Copied!

Building with Ninja

1
ninja -C out/Default
Copied!

Integrating Crashpad

Building Crashpad generates several files that need to be linked with an application in order to generate crash reports.

macOS & Linux

At a minimum, macOS and Linux applications need to be linked with, out/Default/obj/client/libcommon.a, out/Default/obj/client/libclient.a, out/Default/obj/util/libutil.a, and out/Default/obj/third_party/mini_chromium/mini_chromium/base/libbase.a.
MacOS application will need to link with all of the .o files in out/Default/obj/out/Default/gen/util/mach as well.
When building Linux applications, libbase.a needs to be the last Crashpad file specified in the build arguments or the application will not build.
Additionally, ~/crashpad/crashpad and ~/crashpad/crashpad/third_party/mini_chromium/mini_chromium need to be added as include directories.
Finally, out/Default/crashpad_handler needs to be deployed with the application and accessible at runtime.

Windows

At a minimum, Windows applications need to be linked with out\Default\obj\client\common.lib, out\Default\obj\client\client.lib, out\Default\obj\util\util.lib, and out\Default\obj\third_party\mini_chromium\mini_chromium\base\base.lib.
Finally, out\Default\crashpad_handler.exe needs to be deployed with the application and accessible at runtime.

Configuring Crashpad

Add the following includes to the entry point of the application.
1
#include "client/crashpad_client.h"
2
#include "client/crash_report_database.h"
3
#include "client/settings.h"
Copied!
Add a typedef for StringType, add using statements for the base, crashpad and std namespace and declare the following methods at the top of the entry point of the application.
1
#if defined(__APPLE__)
2
typedef std::string StringType;
3
#elif defined(__linux__)
4
typedef std::string StringType;
5
#elif defined(_MSC_VER)
6
typedef std::wstring StringType;
7
#endif
8
9
using namespace base;
10
using namespace crashpad;
11
using namespace std;
12
13
bool initializeCrashpad(void);
14
StringType getExecutableDir(void);
Copied!
Implement the initializeCrashpad method replacing the file paths with valid values.
1
bool initializeCrashpad() {
2
// Get directory where the exe lives so we can pass a full path to handler, reportsDir, metricsDir and attachments
3
StringType exeDir = getExecutableDir();
4
5
// Ensure that handler is shipped with your application
6
FilePath handler(exeDir + "/path/to/crashpad_handler");
7
8
// Directory where reports will be saved. Important! Must be writable or crashpad_handler will crash.
9
FilePath reportsDir(exeDir + "/path/to/crashpad");
10
11
// Directory where metrics will be saved. Important! Must be writable or crashpad_handler will crash.
12
FilePath metricsDir(exeDir + "/path/to/crashpad");
13
14
// Configure url with BugSplat’s public fred database. Replace 'fred' with the name of your BugSplat database.
15
StringType url = "https://fred.bugsplat.com/post/bp/crash/crashpad.php";
16
17
// Metadata that will be posted to the server with the crash report map
18
map<StringType, StringType> annotations;
19
annotations["format"] = "minidump"; // Required: Crashpad setting to save crash as a minidump
20
annotations["database"] = "fred"; // Required: BugSplat appName
21
annotations["product"] = "myCrashpadCrasher"; // Required: BugSplat appName
22
annotations["version"] = "1.0.0"; // Required: BugSplat appVersion
23
annotations["key"] = "Sample key"; // Optional: BugSplat key field
24
annotations["user"] = "[email protected]"; // Optional: BugSplat user email
25
annotations["list_annotations"] = "Sample comment"; // Optional: BugSplat crash description
26
27
// Disable crashpad rate limiting so that all crashes have dmp files
28
vector<StringType> arguments;
29
arguments.push_back("--no-rate-limit");
30
31
// Initialize Crashpad database
32
unique_ptr<CrashReportDatabase> database = CrashReportDatabase::Initialize(reportsDir);
33
if (database == NULL) return false;
34
35
// File paths of attachments to uploaded with minidump file at crash time - default upload limit is 2MB
36
vector<FilePath> attachments;
37
FilePath attachment(exeDir + "/path/to/attachment.txt");
38
attachments.push_back(attachment);
39
40
// Enable automated crash uploads
41
Settings *settings = database->GetSettings();
42
if (settings == NULL) return false;
43
settings->SetUploadsEnabled(true);
44
45
// Start crash handler
46
CrashpadClient *client = new CrashpadClient();
47
bool status = client->StartHandler(handler, reportsDir, metricsDir, url, annotations, arguments, true, true, attachments);
48
return status;
49
}
Copied!
Next, implement the platform-specific getExecutableDir method.

macOS

1
#include <mach-o/dyld.h>
2
#include <vector>
3
4
StringType getExecutableDir() {
5
unsigned int bufferSize = 512;
6
vector<char> buffer(bufferSize + 1);
7
8
if (_NSGetExecutablePath(&buffer[0], &bufferSize)) {
9
buffer.resize(bufferSize);
10
_NSGetExecutablePath(&buffer[0], &bufferSize);
11
}
12
13
char *lastForwardSlash = strrchr(&buffer[0], '/');
14
if (lastForwardSlash == NULL) return NULL;
15
*lastForwardSlash = 0;
16
17
return &buffer[0];
18
}
Copied!

Linux

1
#include <stdio.h>
2
#include <unistd.h>
3
#define MIN(x, y) (((x) < (y)) ? (x) : (y))
4
5
StringType getExecutableDir() {
6
char pBuf[FILENAME_MAX];
7
int len = sizeof(pBuf);
8
int bytes = MIN(readlink("/proc/self/exe", pBuf, len), len - 1);
9
if (bytes >= 0) {
10
pBuf[bytes] = '\0';
11
}
12
13
char* lastForwardSlash = strrchr(&pBuf[0], '/');
14
if (lastForwardSlash == NULL) return NULL;
15
*lastForwardSlash = '\0';
16
17
return pBuf;
18
}
Copied!

Windows

1
StringType getExecutableDir() {
2
HMODULE hModule = GetModuleHandleW(NULL);
3
WCHAR path[MAX_PATH];
4
DWORD retVal = GetModuleFileNameW(hModule, path, MAX_PATH);
5
if (retVal == 0) return NULL;
6
7
wchar_t *lastBackslash = wcsrchr(path, '\\');
8
if (lastBackslash == NULL) return NULL;
9
*lastBackslash = 0;
10
11
return path;
12
}
Copied!
Finally, call the initializeCrashpad method at the entry point of the application.
1
int main(int argc, char *argv[]) {
2
initializeCrashpad();
3
}
Copied!

Generating Symbols

Generating sym files requires the dump_syms tool from the repository of Crashpad’s predecessor, Breakpad. Dump_syms creates sym files from executable binaries so that minidumps can be symbolicated to determine the function names, file names, and line numbers in the call stack.
1
mkdir ~/breakpad
2
cd breakpad
3
fetch breakpad
Copied!

macOS

Build the application with symbolic information (preferably in a separate dSYM file) in order to get fully symbolicated crash reports.
Next, build the Xcode project located at src/src/tools/mac/dump_syms/dump_syms.xcodeproj. Switch the configuration to dump_syms and build the project. The report navigator tab (icon looks like a chat bubble in Xcode 11) will show the file system location with the compiled executable. Run the dump_syms executable.
1
dump_syms -g "/path/to/myApp.app.dSYM" "/path/to/myApp.app/Contents/MacOS/myApp" > myApp.sym
Copied!

Linux

Build the application with symbolic information and a build identifier. Using clang this means building with the -g and -Wl,--build-id arguments.
Next, run ./configure && make in the Breakpad directory. This will generate dump_syms, symupload and minidump_stackwalk.
1
dump_syms /path/to/myApp.out > myApp.out.sym
Copied!

Windows

The dump_syms functionality is built into the symupload utility and can be skipped if the application will be symbolicated remotely. Run dump_syms only if the application will be symbolicated locally or the sym file will be uploaded to a remote server via some means other than symupload.
In order for dump_syms.exe to generate the correct output, applications must be built with symbolic information so that each exe and dll file generates a corresponding pdb file. Generated pdb files must contain full debug information. With Visual Studio, full debug information can be generated with the /Zi compiler argument and the /DEBUG:FULL linker argument. Failure to specify either the /Zi or /DEBUG:FULL arguments will result in dump_syms outputting incorrect sym file data. Additionally the output pdb file must be in the same folder as the corresponding exe or dll file otherwise dump_syms.exe will fail.
In order to run dump_syms.exe a copy of msdia140.dll must be placed in the same folder. If Visual Studio is installed this file can be found at [VisualStudioFolder]\DIA SDK\bin\amd64\msdia140.dll. Copy msdia140.dll into the same folder as dump_syms.exe and run dump_syms.exe.
1
symupload.exe "path/to/myApp.exe" "https://fred.bugsplat.com/post/bp/symbol/breakpadsymbols.php?appName=myApp&appVer=1.0.0"
Copied!
Dump_syms can be built from source so that the debugger can be used for troubleshooting. To build dump_syms clone the gyp repository and run python setup.py install. Next, run gyp ~\breakpad\src\tools\windows\dump_syms\dump_syms.gyp and use Visual Studio to build the sln file generated by gyp. If the build fails with an error that unique_pointer is not part of std add #include <memory> to the top of the file that contains the error and rebuild.

Uploading Symbols

The symupload tool is also part of the Breakpad repository and can be used to upload sym files to your server. Symbols need to be uploaded to a server in order for it to correctly symbolicate a minidump file.

macOS

Build the Xcode project located at src/src/tools/mac/symupload/symupload.xcodeproj. The report navigator tab (icon looks like a chat bubble in Xcode 11) will show you the file system location with the compiled executable. Copy the symupload file into your project and run the executable wrapping the arguments to symupload in quotes.
1
symupload "/path/to/myApp.sym" "https://fred.bugsplat.com/post/bp/symbol/breakpadsymbols.php?appName=myApp&appVer=1.0.0"
Copied!

Windows

In order to use symupload applications must be built with symbolic information so that each exe and dll file generates a corresponding pdb file. Generated pdb files must contain full debug information. Full debug information can be generated with the /Zi compiler argument and the /DEBUG:FULL linker argument. Failure to specify either the /Zi or /DEBUG:FULL arguments will result in symupload failing entirely. The output pdb file must be in the same folder as the corresponding exe or dll file.
In order to run symupload.exe a copy of msdia140.dll must be placed in the same folder. If Visual Studio is installed this file can be found at [VisualStudioFolder]\DIA SDK\bin\amd64\msdia140.dll. Copy msdia140.dll into the same folder as symupload.exe and run symupload.exe.
1
dump_syms.exe "path/to/myApp.exe" > myApp.pdb.sym
Copied!
Symupload can be built from source so that the debugger can be used for troubleshooting. To build symupload clone the gyp repository and run python setup.py install. Next, run gyp ~\breakpad\src\tools\windows\symupload\symupload.gyp and use Visual Studio to build the sln file generated by gyp. If the build fails with an error that unique_pointer is not part of std add #include <memory> to the top of the file that contains the error and rebuild.

Symbolicating Crash Reports

Minidump_stackwalk is another tool in the Breakpad repository that is responsible for the symbolication of minidump files. In order to correctly symbolicate minidumps, sym files need to be nested at least 2 folders deep. The topmost parent folder’s name must equal the sym files module name. The first child folder’s name must equal the module id. Additionally, the sym file name must also match the module name. The module id and module name can be found in the module record of the sym file.
For example the module myApp with the module id 1A67F3DEAACA3B209D9992871B2620AA0 must be located at /path/to/symbols/myApp/1A67F3DEAACA3B209D9992871B2620AA0/myApp.sym.

macOS & Linux

Minidump_stackwalk is built when building Breakpad.
1
cd ~/breakpad/src && configure && make
Copied!
Run minidump_stackwalk passing it a path to a dmp file and a path to a symbols directory. The folders in the symbols directory need to be laid out following the pattern module_name/module_id/module_name.sym:
1
minidump_stackwalk -m "/path/to/minidump.dmp" "/path/to/symbols"
Copied!

Windows

Minidump_stackwalk is part of the Breakpad processor sln which is generated by gyp
1
gyp ~/breakpad/src/src/processor/processor.gyp
Copied!
At the time of writing the processor.sln file will not build on Windows 10 with Visual Studio 2019. However, minidumps generated on the Windows platform can be symbolicated on macOS or by a 3rd party service such as BugSplat. Additionally, minidumps generated by the Crashpad library can also be symbolicated via Debugging Tools for Windows given the .exe, .dll and .pdb files are made available to WinDBG.

Troubleshooting

Most issues symbolicating dump files can be traced back to mismatched module ids. Anything that modifies a given executable (code-signing, anti-cheat) must be performed before dump_syms and symupload are run. Every time an executable is modified dump_syms and symupload need to be re-run. The name and id of the module loaded at runtime can be found in the minidump_stackwalk output. The module name and id must match the module name and id of the generated sym file in order for minidump_stackwalk to correctly symbolicate the minidump file.

References

Last modified 3mo ago