diff options
| author | Ted Mielczarek <ted@mielczarek.org> | 2016-03-29 15:32:47 -0400 |
|---|---|---|
| committer | Ted Mielczarek <ted@mielczarek.org> | 2016-03-29 15:32:47 -0400 |
| commit | d091e5103f3a9305b56d5aa9ef18e18306d32786 (patch) | |
| tree | 86a3db027d709035b6966568e28651f8f8352d6b /src/client/windows/handler/exception_handler.cc | |
| parent | Have dump_syms output the full symbol table. (diff) | |
| download | breakpad-d091e5103f3a9305b56d5aa9ef18e18306d32786.tar.xz | |
Make EXC_BAD_ACCESS / EXC_I386_GPFLT print nicely in the processor
Currently EXC_BAD_ACCESS doesn't support EXC_I386_GPFLT as
exception_flags for pretty-printing in the processor, but this happens
for a lot of things:
http://opensource.apple.com/source/xnu/xnu-2050.24.15/osfmk/i386/trap.c
(search for EXC_I386_GPFLT).
And we get a lot of these in the wild:
https://crash-stats.mozilla.com/search/?reason=%3DEXC_BAD_ACCESS+%2F+0x0000000d&cpu_name=amd64&_facets=signature&_facets=address&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=address#crash-reports
This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".
Additionally, this patch fixes some other cases where x86-64 wasn't being handled in the same way as x86, and fixes some x86-specific exception flags to be stringified with I386 in the output.
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1833123002 .
Diffstat (limited to 'src/client/windows/handler/exception_handler.cc')
0 files changed, 0 insertions, 0 deletions