New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 29 link

Starred by 17 users

Issue metadata

Status: Started
vslow; not on Chrome

Blocked on:
issue 88

Sign in to add a comment

Crashpad processor

Project Member Reported by, Mar 28 2015

Issue description

Crashpad should have its own processor. Here are some ideas:

 - Consume raw DWARF and native image files, no more dump_syms.
    - Enables more than just function, file name, and line number. Function parameters and variables can also be decoded.
    - The processor may still need to support dump_syms for compatibility.
    - DWARF data can be quite large, and it may be impractical to do this for many Crashpad users. -gline-tables-only is an option to reduce DWARF, but debugging information is lost and function parameters and variables cannot be extracted. A tool can be provided to minimize DWARF by subsetting the available data, if no such tool already exists.
    - For Windows, it will need to support something dump_syms-like, since it will not likely be able to read .pdb files directly on other platforms.
 - Built on the snapshot library, consumes live/crashed process images in addition to minidump files. In the future, will support native core files (bug 28) and more.
 - Stackwalking and other support to be provided by LLVM?

This is a lot of work. I expect other bugs for specific tasks to be filed, and for this bug to be blocked on those.

Comment 1 by, Apr 1 2015

Until this rather large project is implemented, I think it might make sense to port dump_syms over from Breakpad to Crashpad. One of the strengths of Crashpad (IMHO) is that compiling it is so easy now that is done from the command line. Granted I have no idea how much code and effort this would require. :-)
Project Member

Comment 2 by, Apr 1 2015

No code will be coming over as-is from Breakpad. It doesn’t meet the standards for design, documentation, quality, and testability.

We made an exception for client/simple_string_dictionary and brought it over almost unchanged because it actually did meet the standards.

If the problem you’re having is just that dump_syms is difficult to build, you could take a look at Chromium’s .gyp file for it ( You can probably swipe the target starting at line 182 out of that file and adapt it for your needs. You’ll also notice the comment on line 239 that kind of makes part of my point.

Otherwise, you can build dump_syms with Breakpad’s .xcodeproj for it:

$ cd …/breakpad/src/tools/mac/dump_syms
$ xcodebuild -target dump_syms -configuration Release \ \
    SDKROOT=macosx10.9 \
$ file build/Release/dump_syms
build/Release/dump_syms: Mach-O 64-bit executable x86_64
What's the motivation here? I get the desire to rewrite the client bits due to changing platform expectations, but rewriting the processor seems like busywork.

Also re: PDB files, I've got a mostly-compatible Windows dump_syms replacement under a BSD license that works on POSIX:

If you wanted to consume PDB files directly in the processor you could start with that code.
Project Member

Comment 4 by, May 8 2015

The Breakpad processor has held up better than most of the rest of the Breakpad components, but that doesn’t mean it’s in great shape, and I don’t think that it would be easy to achieve some of the things we want to do in that codebase. The lack of strong tests really works against it, because even for the features that would be feasible to work into the Breakpad processor, there’s not a very strong guarantee that sweeping changes wouldn’t break anything.

Some of the things we’d like to do involve data sources other than minidump files, including native core files and live remote processes. Breakpad is tied heavily to the minidump format. We’d like to be able to walk stacks using native debugging data without having to run dump_syms where possible. Although Breakpad allows the dump_syms format to be easily replaced by something else, that “something else” needs to carry dump_syms-like data, such as STACK lines that can be fed to the postfix evaluator. I like how Jim was able to work DWARF into that scheme, but not all of DWARF is supported (DW_CFA_expression is missing, for example) and the requirement to work everything into STACK terms really does turn out to be limiting. We’d also like to take advantage of some of the better debugging tools that just didn’t exist when Breakpad first came into existence: I don’t think we should need to own the stackwalker implementations, for example, and I do think that we should be able to do things like recover parameters and variables from memory (this has always been the most-requested item).

None of this is busywork (and I think that’s a borderline offensive assertion for you to make). The Breakpad processor’s design and assumptions about minidump and dump_syms formats would really hold back progress. Breakpad’s processor is tied up with the minidump format, which frustrates attempts to move to interesting remote debugging-type models. Breakpad’s stackwalker is tied up with the dump_syms format and extracting any more information from minidumps than it does now would require a bunch of dump_syms work too, and dump_syms has already proven itself as a flakier part of the chain.
Project Member

Comment 5 by, Oct 30 2015

Labels: -priority-medium Priority-2
Project Member

Comment 6 by, Oct 30 2015

Labels: -type-defect Type-Bug
Project Member

Comment 7 by, Oct 30 2015

Status: Available
Project Member

Comment 8 by, Jan 4 2017

Status: Started (was: Available)
I'm going to start looking at (some of?) this. I some preliminary thoughts in a document here: .
Project Member

Comment 9 by, Jan 5 2017

The following revision refers to this bug:

commit 2d68949f7ff7502c3c6fd988552308abec495c9f
Author: Scott Graham <>
Date: Thu Jan 05 02:56:45 2017

Pull LLVM/Clang/LLDB into third_party

This might feel a bit premature, but I feel fairly confident that basing
a lot of the processing on LLDB is the way to go, so I plan to start by
integrating it into our build process.

(I think probably moving from gyp to GN first makes sense, so I can defer
landing this until after that's farther along if you like.)


Change-Id: I85ee44f4e777f9d7ce521c4caf10ead21ffd8818
Reviewed-by: Mark Mentovai <>


Sign in to add a comment