Make EXC_BAD_ACCESS / EXC_I386_GPFLT print nicely in the processor

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=

Committed: https://chromium.googlesource.com/breakpad/breakpad/+/d091e5103f3a9305b56d5aa9ef18e18306d32786

[Mark Mentovai, 2016-03-25 14:52:24]

LGTM otherwise. It’s probably worth implementing some of the other subcodes from
the EXC_I386_* family too.

https://codereview.chromium.org/1833123002/diff/1/src/processor/minidump_proc...
File src/processor/minidump_processor.cc (right):

https://codereview.chromium.org/1833123002/diff/1/src/processor/minidump_proc...
src/processor/minidump_processor.cc:754: reason.append("EXC_GPFLT");
EXC_I386_GPFLT. Fix the change description too.

[Ted Mielczarek, 2016-03-25 15:46:44]

In practice this is the only non-stringified value I see in our crash reports:
https://crash-stats.mozilla.com/search/?reason=%5EEXC_BAD_ACCESS&cpu_name=amd...
(if you click on the "Reason Facet" tab you can see them grouped).

It looks like it's possible for it to be any kern_return_t value from
`vm_fault`, but that function is sufficiently complex that I don't have the
energy to actually look into it:
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/vm/vm_fault.c

https://codereview.chromium.org/1833123002/diff/1/src/processor/minidump_proc...
File src/processor/minidump_processor.cc (right):

https://codereview.chromium.org/1833123002/diff/1/src/processor/minidump_proc...
src/processor/minidump_processor.cc:754: reason.append("EXC_GPFLT");
On 2016/03/25 14:52:24, Mark Mentovai wrote:
> EXC_I386_GPFLT. Fix the change description too.

I copied this from:
https://chromium.googlesource.com/breakpad/breakpad/+/master/src/processor/mi...

Do you want that changed or should we leave it?

[Mark Mentovai, 2016-03-25 16:23:52]

Ted Mielczarek wrote:
> In practice this is the only non-stringified value I see in our crash reports:
>
https://crash-stats.mozilla.com/search/?reason=%5EEXC_BAD_ACCESS&cpu_name=amd...
> (if you click on the "Reason Facet" tab you can see them grouped).
> 
> It looks like it's possible for it to be any kern_return_t value from
> `vm_fault`, but that function is sufficiently complex that I don't have the
> energy to actually look into it:
> http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/vm/vm_fault.c

I was thinking about codes for exceptions other than EXC_BAD_ACCESS. It’s really
easy to get EXC_ARITHMETIC/EXC_I386_DIV and EXC_BAD_INSTRUCTION/EXC_I386_INVOP,
for example. But if you want to leave this scoped to just EXC_BAD_ACCESS, I
agree that EXC_I386_GPFLT is the one you’re most likely to see.

>
https://codereview.chromium.org/1833123002/diff/1/src/processor/minidump_proc...
> File src/processor/minidump_processor.cc (right):
> 
>
https://codereview.chromium.org/1833123002/diff/1/src/processor/minidump_proc...
> src/processor/minidump_processor.cc:754: reason.append("EXC_GPFLT");
> On 2016/03/25 14:52:24, Mark Mentovai wrote:
> > EXC_I386_GPFLT. Fix the change description too.
> 
> I copied this from:
>
https://chromium.googlesource.com/breakpad/breakpad/+/master/src/processor/mi...
> 
> Do you want that changed or should we leave it?

Nope, we should fix those too.

[Ted Mielczarek, 2016-03-25 16:35:46]

Description was changed from

==========
Make EXC_BAD_ACCESS / EXC_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+0x000000...

This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".

R=mark@chromium.org
BUG=
==========

to

==========
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+0x000000...

This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".

R=mark@chromium.org
BUG=
==========

[Ted Mielczarek, 2016-03-25 16:44:34]

On 2016/03/25 16:23:52, Mark Mentovai wrote:
> I was thinking about codes for exceptions other than EXC_BAD_ACCESS. It’s
really
> easy to get EXC_ARITHMETIC/EXC_I386_DIV and
EXC_BAD_INSTRUCTION/EXC_I386_INVOP,
> for example. But if you want to leave this scoped to just EXC_BAD_ACCESS, I
> agree that EXC_I386_GPFLT is the one you’re most likely to see.

You're right:
https://crash-stats.mozilla.com/search/?reason=~0x&platform=Mac+OS+X&_facets=...


We have barely any Mac users on 32-bit anymore, so I'm not really sure of what
we're missing there, but it looks like all of these cases are just "we forgot to
handle x86-64 in the x86 case statements". I'll fix that, it's just a few extra
lines.

[Ted Mielczarek, 2016-03-25 16:55:13]

Description was changed from

==========
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+0x000000...

This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".

R=mark@chromium.org
BUG=
==========

to

==========
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+0x000000...

This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".

There were also some other cases where x86-64 wasn't being handled in the same
way as x86, so this patch fixes those as well.

R=mark@chromium.org
BUG=
==========

[Ted Mielczarek, 2016-03-29 12:10:43]

Did you want to give this another once-over with the extra changes or does your
LGTM stand?

[Mark Mentovai, 2016-03-29 15:21:57]

LGTM otherwise

https://codereview.chromium.org/1833123002/diff/20001/src/processor/minidump_...
File src/processor/minidump_processor.cc (right):

https://codereview.chromium.org/1833123002/diff/20001/src/processor/minidump_...
src/processor/minidump_processor.cc:818: reason.append("EXC_INVTSSFLT");
All of the rest of these are EXC_I386_* too.

[Ted Mielczarek, 2016-03-29 19:31:23]

Description was changed from

==========
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+0x000000...

This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".

There were also some other cases where x86-64 wasn't being handled in the same
way as x86, so this patch fixes those as well.

R=mark@chromium.org
BUG=
==========

to

==========
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+0x000000...

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=
==========

[Ted Mielczarek, 2016-03-29 19:32:50]

Description was changed from

==========
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+0x000000...

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=
==========

to

==========
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+0x000000...

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=

Committed:
https://chromium.googlesource.com/breakpad/breakpad/+/d091e5103f3a9305b56d5aa...
==========

[Ted Mielczarek, 2016-03-29 19:32:52]

Committed patchset #2 (id:20001) manually as
d091e5103f3a9305b56d5aa9ef18e18306d32786 (presubmit successful).