Refactoring Crashpad + uploading debug symbols by elviscapiaq · Pull Request #691 · google/dive

elviscapiaq · 2026-01-06T19:00:45Z

- This change implements Crashpad as the primary crash reporting system across all platforms
  (Linux, Windows, and macOS), replacing the existing absl::crashhandler.
- Symbol Generation: Developers are now required to install dump_syms via the Rust toolchain
  or the Linux package manager to generate debug symbols.
- Symbol Uploads: Added support for uploading symbols to the Crashpad server using curl via
  PowerShell (Windows) or Bash (macOS/Linux).
- Distribution: Included the crashpad_handler executable in the Dive UI output directory for
  both development and release builds.
- Debug symbols are only generated and uploaded to the Crashpad server for a release build
  (DIVE_RELEASE_TYPE=RelWithDebInfo).

breakpad_tools.cmake

elviscapiaq · 2026-01-12T21:56:39Z

Tested on Windows and Linux.

@angela28chen @GrantComm, could you please help me test this PR on macOS? Since I’m guessing the Crashpad path dependencies for macOS, please follow this workflow:

Prepare the build system: cmake . -DDIVE_RELEASE_TYPE=RelWithDebInfo -G "Ninja Multi-Config" -Bbuild
Build the project: ninja -C build -f build-RelWithDebInfo.ninja or cmake --build build --config=RelWithDebInfo

What to verify:

Symbol Generation/Upload: If symbols are successfully generated and uploaded to the server, you should see this message after building the project:
[SUCCESS] Symbol uploaded and finalized.
Crashpad Initialization: When Dive UI is launched, you should see:
Crashpad initialization succeeded.

If you don't see these messages, please post the error log here.

On another note, could you also investigate why the Regression_StackOverflow test is failing on macOS with a timeout? My guess is that because crashpad_handler now runs out-of-process, we might need to increase the timeout.

scripts/sym-upload-v2.sh

ui/main.cpp

BUILD.md

angela28chen · 2026-01-14T22:28:37Z

What to verify:

Symbol Generation/Upload: If symbols are successfully generated and uploaded to the server, you should see this message after building the project:
[SUCCESS] Symbol uploaded and finalized.

I got:

17:23:36 [ERROR] A panic occurred at /Users/chenangela/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/dump_syms-2.3.5/src/utils.rs:15: Unable to open the file /Users/chenangela/src/git/dive/build/ui/RelWithDebInfo/dive.app/Contents/MacOS/dive.dSYM


chenangela@H:~/src/git/dive$ ls /Users/chenangela/src/git/dive/build/ui/RelWithDebInfo/dive.app/Contents/MacOS/dive.dSYM
ls: /Users/chenangela/src/git/dive/build/ui/RelWithDebInfo/dive.app/Contents/MacOS/dive.dSYM: No such file or directory
chenangela@H:~/src/git/dive$ ls /Users/chenangela/src/git/dive/build/ui/RelWithDebInfo/dive.app/Contents/MacOS/
crashpad_handler	dive			dive.sym		plugins

Also, do I need to set something up with api key?

elviscapiaq · 2026-02-09T22:20:04Z

Tested on Windows and Linux. @angela28chen , could you help me to test on macOS?
I would like to see if uploading debug symbols and initializing Crashpad on macOS are still working with the python scripts.
Note that, we need to set DIVE_BUILD_WITH_CRASHPAD=ON and UPLOAD_DEBUG_SYMBOLS=ON on a RelWithDebInfo build.

BUILD.md

ui/main.cpp

scripts/upload_debug_symbols_to_crashpad.py

src/dive/crash_report/CMakeLists.txt

scripts/upload_debug_symbols_to_crashpad.py

elviscapiaq · 2026-02-11T22:56:41Z

Tested on Windows and Linux.

angela28chen · 2026-02-12T17:44:51Z

CMakeLists.txt


 option(DIVE_BUILD_WITH_SANITIZER "Build Dive with sanitizers" OFF)

+option(DIVE_BUILD_WITH_CRASHPAD "Build Dive with Crashpad" OFF)


I thought that this option is meant to be ON by default? As discussed here: #691 (comment). Please correct me if this is wrong.

I think it's better to have the default (no-option specified) behavior be the one that we want, rather than depend on users to know that they need to be supplying the additional flag -DDIVE_BUILD_WITH_CRASHPAD=ON to achieve the correct behavior for RelWithDebInfo builds.

I believe currently in the presubmits the Debug and RelWithDebInfo builds are both using crash_report_absl.cpp? Shouldn't the RelWithDebInfo be using crash_report_crashpad.cpp instead?

Thanks for pointing this out. I set up the value to ON and also when the build mode is RelWithDebInfo, then we use the crash_report_crashpad.cpp, otherwise, it uses crash_report_absl.cpp.

so i guess this comment is not valid anymore since the default is OFF?

Now the default value is On as discussed below.

angela28chen · 2026-02-12T17:53:48Z

Also just since this PR is very large (+826 -450) and is still in the review process, what do you think about breaking this into smaller PRs? For example, the part with refactoring the platform-specific shell scripts into third_party/dive_crashpad/build_crashpad.py could probably be its own PR?

elviscapiaq · 2026-02-17T20:21:22Z

Also just since this PR is very large (+826 -450) and is still in the review process, what do you think about breaking this into smaller PRs? For example, the part with refactoring the platform-specific shell scripts into third_party/dive_crashpad/build_crashpad.py could probably be its own PR?

@angela28chen , I agree with that. I split this PR into two smaller ones: the first involves refactoring dive_crashpad, and the second is for uploading the debug symbols to the Crashpad server. I plan to push these as different commits. Let me know what you think.

elviscapiaq · 2026-02-18T15:52:56Z

Fixed the issue, all presubmit tests are passing now.

angela28chen · 2026-02-18T20:32:07Z

Also just since this PR is very large (+826 -450) and is still in the review process, what do you think about breaking this into smaller PRs? For example, the part with refactoring the platform-specific shell scripts into third_party/dive_crashpad/build_crashpad.py could probably be its own PR?

@angela28chen , I agree with that. I split this PR into two smaller ones: the first involves refactoring dive_crashpad, and the second is for uploading the debug symbols to the Crashpad server. I plan to push these as different commits. Let me know what you think.

That sounds good to me!

wangra-google · 2026-02-19T22:45:13Z

CMakeLists.txt


 option(DIVE_BUILD_WITH_SANITIZER "Build Dive with sanitizers" OFF)

+option(DIVE_BUILD_WITH_CRASHPAD "Build Dive with Crashpad" ON)


just to make sure i understand this, now with both Debug and RelWithDebInfo build, we build crashpad? or do we disable crashpad for Debug somewhere else?

We are building Crashpad for both: Debug and RelWithDebInfo, however, we only use Crashpad for RelWithDebInfo while for Debug we use the abls:crashhandler.
To solve this unnecesary building for a Debug build, I am:

Seting DIVE_BUILD_WITH_CRASHPAD=OFF by default.

Updating the README.md to be clear about it: To build with Crashpad, set the CMake flag "DIVE_BUILD_WITH_CRASHPAD=ON" and ensure the build type is set to "RelWithDebInfo".

@angela28chen , let me know what you think about this.

regarding "Updating the README.md to be clear about it: To build with Crashpad, set the CMake flag "DIVE_BUILD_WITH_CRASHPAD=ON" and ensure the build type is set to "RelWithDebInfo"."

Can we do this automatically: DIVE_BUILD_WITH_CRASHPAD=ON if build type is RelWithDebInfo?

I have investigated the reliability of that point and it seems that the current change makes it impossible. To build DIVE, we have two stages:

Configuration stage: Here, we must fetch or find the dependencies. Crashpad should be fetched if it is not present.

Building stage: Here, we build for [Debug, Release, RelWithDebInfo], and we cannot change the value of DIVE_BUILD_WITH_CRASHPAD to ON or OFF (this action is performed in step 1). If we want a RelWithDebInfo build, we must have fetched Crashpad, meaning we need DIVE_BUILD_WITH_CRASHPAD=ON in step 1.T

Therefore, if I understand correctly, we have two alternatives:

Set DIVE_BUILD_WITH_CRASHPAD=ON by default, and fetch Crashpad if it does not exist, even if the build type is not RelWithDebInfo. This means we always fetch Crashpad for all builds but only link it for the RelWithDebInfo build.

Set DIVE_BUILD_WITH_CRASHPAD=OFF by default and Crashpad is never fetched, however, for a RelWithDebInfo build we are not going to link Crashpad as it does not exist, and we fallback to absl:handler. Here we need to set DIVE_BUILD_WITH_CRASHPAD=ON during configuration stage for RelWithDebInfo build.

What do you think is a better approach?

Personally, I feel option 1 is better as when developers build RelWithDebInfo, they automatically get the correct crash handler without remembering to flip a CMake flag. Building RelWithDebInfo should use Crashpad without requiring manual intervention.

I agreee with that. I updated the value to ON.

- This change implements Crashpad as the primary crash reporting system across all platforms (Linux, Windows, and macOS), replacing the existing absl::crashhandler. - Symbol Generation: Developers are now required to install dump_syms via the Rust toolchain or the Linux package manager to generate debug symbols. - Symbol Uploads: Added support for uploading symbols to the Crashpad server using curl via PowerShell (Windows) or Bash (macOS/Linux). - Distribution: Included the crashpad_handler executable in the Dive UI output directory for both development and release builds. - Debug symbols are only generated and uploaded to the Crashpad server for a release build (DIVE_RELEASE_TYPE=RelWithDebInfo).

elviscapiaq · 2026-02-26T15:20:44Z

Ready for review. I have put all commits into two PRs.

wangra-google · 2026-02-27T16:55:01Z

CMakeLists.txt


+option(DIVE_BUILD_WITH_CRASHPAD "Build Dive with Crashpad" ON)
+
+option(UPLOAD_DEBUG_SYMBOLS "Enable uploading debug symbols to Crashpad" OFF)


for this flag, i guess we need to manually change it to ON when we prepare the new release?

angela28chen · 2026-02-27T21:18:38Z

Ready for review. I have put all commits into two PRs.

Sorry can you clarify which two PRs? I only see this one #691

If you're talking about the two commits on this PR, are you planning to merge without squashing?

elviscapiaq force-pushed the debug_symbols branch 3 times, most recently from 50a5f6b to 8186325 Compare January 7, 2026 16:51

elviscapiaq changed the title ~~Adding breakpad tools~~ Adds Crashpad to Dive UI Jan 7, 2026

wangra-google reviewed Jan 7, 2026

View reviewed changes

breakpad_tools.cmake Outdated Show resolved Hide resolved

elviscapiaq force-pushed the debug_symbols branch 11 times, most recently from 13f9f2e to 58afbcc Compare January 12, 2026 21:29

elviscapiaq changed the title ~~Adds Crashpad to Dive UI~~ Adds Crashpad support to Dive UI Jan 12, 2026

elviscapiaq force-pushed the debug_symbols branch 2 times, most recently from 6f47f8f to 4089ee9 Compare January 12, 2026 21:43

elviscapiaq requested review from GrantComm, angela28chen and wangra-google January 12, 2026 21:56

hysw reviewed Jan 12, 2026

View reviewed changes

scripts/sym-upload-v2.sh Outdated Show resolved Hide resolved

hysw reviewed Jan 12, 2026

View reviewed changes

scripts/sym-upload-v2.sh Outdated Show resolved Hide resolved

hysw reviewed Jan 12, 2026

View reviewed changes

ui/main.cpp Outdated Show resolved Hide resolved

hysw reviewed Jan 12, 2026

View reviewed changes

BUILD.md Outdated Show resolved Hide resolved

elviscapiaq marked this pull request as ready for review January 14, 2026 21:38

angela28chen reviewed Jan 14, 2026

View reviewed changes

BUILD.md Outdated Show resolved Hide resolved

elviscapiaq force-pushed the debug_symbols branch from 25f1be9 to af0ec01 Compare February 9, 2026 22:15

elviscapiaq requested review from angela28chen and wangra-google February 10, 2026 15:31

angela28chen reviewed Feb 11, 2026

View reviewed changes

elviscapiaq force-pushed the debug_symbols branch from 3c3f0e1 to 3302bb4 Compare February 11, 2026 22:55

elviscapiaq requested a review from angela28chen February 11, 2026 22:56

angela28chen reviewed Feb 12, 2026

View reviewed changes

elviscapiaq force-pushed the debug_symbols branch from 3302bb4 to 3567521 Compare February 17, 2026 20:14

elviscapiaq changed the title ~~Initializes Crashpad in Dive UI~~ Refactoring Crashpad + uploading debug symbols Feb 17, 2026

elviscapiaq requested a review from angela28chen February 17, 2026 20:22

elviscapiaq force-pushed the debug_symbols branch from 3567521 to efd9d76 Compare February 18, 2026 14:59

Refactoring Crashpad

652321c

elviscapiaq force-pushed the debug_symbols branch from efd9d76 to 8708c6c Compare February 18, 2026 15:13

wangra-google reviewed Feb 19, 2026

View reviewed changes

wangra-google previously approved these changes Feb 19, 2026

View reviewed changes

elviscapiaq dismissed wangra-google’s stale review via 4df99b9 February 23, 2026 20:00

elviscapiaq requested a review from wangra-google February 23, 2026 22:35

elviscapiaq force-pushed the debug_symbols branch from ae983c5 to 28655b1 Compare February 26, 2026 15:16

elviscapiaq force-pushed the debug_symbols branch from 28655b1 to fda25a3 Compare February 26, 2026 15:18

wangra-google reviewed Feb 27, 2026

View reviewed changes

wangra-google approved these changes Feb 27, 2026

View reviewed changes


		option(DIVE_BUILD_WITH_SANITIZER "Build Dive with sanitizers" OFF)

		option(DIVE_BUILD_WITH_CRASHPAD "Build Dive with Crashpad" OFF)


		option(DIVE_BUILD_WITH_CRASHPAD "Build Dive with Crashpad" ON)

		option(UPLOAD_DEBUG_SYMBOLS "Enable uploading debug symbols to Crashpad" OFF)

Conversation

elviscapiaq commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

elviscapiaq commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

angela28chen commented Jan 14, 2026

Uh oh!

elviscapiaq commented Feb 9, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

elviscapiaq commented Feb 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

angela28chen commented Feb 12, 2026

Uh oh!

elviscapiaq commented Feb 17, 2026

Uh oh!

elviscapiaq commented Feb 18, 2026

Uh oh!

angela28chen commented Feb 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elviscapiaq commented Feb 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

angela28chen commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

elviscapiaq commented Jan 6, 2026 •

edited

Loading

elviscapiaq commented Jan 12, 2026 •

edited

Loading