Copy the register context before calling StackWalk64

Copy the register context before calling StackWalk64

StackWalk64 modifies the register context in place as it unwinds.
This makes it so that chained exception filters (think ASan) see
the register context after unwinding. They end up printing truncated
stack traces, making ClusterFuzz sad.

R=jam@chromium.org,ochang@chromium.org
BUG=533350
TEST=Manually ran ToolsSanityTest.AddressSanitizerNullDerefCrashTest, verified correct ASan report

Committed: https://crrev.com/0565cdd65d0a9ce19097d23b4cd6543943c0e78d
Cr-Commit-Position: refs/heads/master@{#352621}

[Oliver Chang, 2015-10-05 20:00:07]

thanks a lot for fixing this!

not an owner, but lgtm.

[jam, 2015-10-05 20:44:01]

On 2015/10/05 20:00:07, Oliver Chang wrote:
> thanks a lot for fixing this!
> 
> not an owner, but lgtm.

you should look for an owner in base/ (top level is a last resort)

[Reid Kleckner, 2015-10-05 22:16:19]

On 2015/10/05 20:44:01, jam wrote:
> you should look for an owner in base/ (top level is a last resort)

I listed you as a reviewer as this is a response to your CL
https://chromium.googlesource.com/chromium/src/+/79dc59ac7602413181079ecb4638....
After this CL, WinASan symbolization stopped working. Not your fault, of course,
since there's no automated testing for this.

Speaking of which, testing this is tricky. I'm not sure PDBs are available
everywhere we run the tests. I'm going to give a shot, though. We have something
like this, just for heap UAF, in sandbox/win/src/address_sanitizer_test.cc.

[jam, 2015-10-05 22:43:12]

jam@chromium.org changed reviewers:
+ ananta@chromium.org, scottmg@chromium.org

[jam, 2015-10-05 22:45:48]

On 2015/10/05 22:16:19, Reid Kleckner wrote:
> On 2015/10/05 20:44:01, jam wrote:
> > you should look for an owner in base/ (top level is a last resort)
> 
> I listed you as a reviewer as this is a response to your CL
>
https://chromium.googlesource.com/chromium/src/+/79dc59ac7602413181079ecb4638....
> After this CL, WinASan symbolization stopped working. Not your fault, of
course,
> since there's no automated testing for this.
> 
> Speaking of which, testing this is tricky. I'm not sure PDBs are available
> everywhere we run the tests

Yes, should be at this point (see below)

> I'm going to give a shot, though. We have something
> like this, just for heap UAF, in sandbox/win/src/address_sanitizer_test.cc.

ah, sorry about that.

I had changed it because while we were debugging various failures, there was a
theory that windows was reading extra information past the public struct. That
might not be true though. I should have tried undoing that after all the fixes
were in place.

as long as ContentBrowserTest.BrowserCrashCallStack and
ContentBrowserTest.RendererCrashCallStack, any change here is fine. I can't tell
though because you haven't run try jobs yet :)

[Reid Kleckner, 2015-10-05 23:06:23]

The CQ bit was checked by rnk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-05 23:07:06]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1387913002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1387913002/1

[commit-bot: I haz the power, 2015-10-06 03:40:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-06 03:40:01]

Dry run: This issue passed the CQ dry run.

[jam, 2015-10-06 14:58:21]

lgtm

[Reid Kleckner, 2015-10-06 16:42:01]

The CQ bit was checked by rnk@chromium.org

[commit-bot: I haz the power, 2015-10-06 16:42:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1387913002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1387913002/1

[commit-bot: I haz the power, 2015-10-06 16:48:38]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-06 16:49:37]

Patchset 1 (id:??) landed as
https://crrev.com/0565cdd65d0a9ce19097d23b4cd6543943c0e78d
Cr-Commit-Position: refs/heads/master@{#352621}