Fix false-positive ASAN detection with the stack profiler on win64

Fix false-positive ASAN detection with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous namespace'::SuspendThreadAndRecordStack+0x21f (D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous namespace'::NativeStackSamplerWin::RecordStackSample D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41

R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
Committed: https://crrev.com/4e9250a7663d37a3490b2aa936a0b634af518670
Cr-Commit-Position: refs/heads/master@{#433256}

[etienneb, 2016-11-14 18:58:48]

Description was changed from

==========
Fix false-positive ASAN deteciton with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

to

==========
Fix false-positive ASAN deteciton with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

[etienneb, 2016-11-14 18:59:19]

etienneb@chromium.org changed reviewers:
- thakis@google.com

[etienneb, 2016-11-14 18:59:33]

etienneb@chromium.org changed reviewers:
+ thakis@chromium.org

[etienneb, 2016-11-14 19:03:43]

Description was changed from

==========
Fix false-positive ASAN deteciton with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

to

==========
Fix false-positive ASAN detection with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

[etienneb, 2016-11-14 20:37:20]

PTAL.

[etienneb, 2016-11-14 20:38:23]

etienneb@chromium.org changed reviewers:
+ rnk@chromium.org mike wittman - ooo to nov.15
- rnk@google.com, wittman@chromium.org

[etienneb, 2016-11-14 20:38:48]

etienneb@chromium.org changed reviewers:
+ rnk@chromium.org, wittman@chromium.org
- rnk@chromium.org mike wittman - ooo to nov.15

[Reid Kleckner, 2016-11-15 00:16:31]

This is the right fix, but I'll leave it to base owners to decide how they want
the macro spelled or if they want ifdefs to use memcpy in non-asan builds.

lgtm

[Mark Mentovai, 2016-11-15 01:34:08]

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h
File base/compiler_specific.h (right):

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h#ne...
base/compiler_specific.h:165: #endif
#ifdef #if #endif #endif #ifndef #endif

What a mouthful. How about:

#if defined(__has_attribute) && __has_attribute(no_sanitize)
#else
#endif

?

[Nico, 2016-11-15 15:25:38]

lgtm once Mark is happy, but style guide discourages `ifdef` and `ifndef`

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h
File base/compiler_specific.h (right):

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h#ne...
base/compiler_specific.h:165: #endif
On 2016/11/15 01:34:07, Mark Mentovai wrote:
> #ifdef #if #endif #endif #ifndef #endif
> 
> What a mouthful. How about:
> 
> #if defined(__has_attribute) && __has_attribute(no_sanitize)
> #else
> #endif
> 
> ?

gcc doesn't like that; && early-terminates execution but not parsing:

thakis@thakis:~/src/chrome/src$ cat test.cc
#if defined(__has_attribute) && __has_attribute(foo)
#endif
thakis@thakis:~/src/chrome/src$ gcc -c test.cc
test.cc:1:48: error: missing binary operator before token "("
 #if defined(__has_attribute) && __has_attribute(foo

+1 on `if defined` instead of `ifdef` though.

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h#ne...
base/compiler_specific.h:166: #ifndef NO_SANITIZE
alos `if !defined` instead of `ifndef`

[etienneb, 2016-11-15 15:45:01]

thanks Nico.
I was not aware of the GCC parsing issue. Good to know.

Marc, PTANL?

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h
File base/compiler_specific.h (right):

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h#ne...
base/compiler_specific.h:165: #endif
On 2016/11/15 01:34:07, Mark Mentovai wrote:
> #ifdef #if #endif #endif #ifndef #endif
> 
> What a mouthful. How about:
> 
> #if defined(__has_attribute) && __has_attribute(no_sanitize)
> #else
> #endif
> 
> ?

Done.

https://codereview.chromium.org/2495413002/diff/1/base/compiler_specific.h#ne...
base/compiler_specific.h:166: #ifndef NO_SANITIZE
On 2016/11/15 15:25:37, Nico wrote:
> alos `if !defined` instead of `ifndef`

Done.

[Mark Mentovai, 2016-11-15 16:52:04]

LG otherwise

https://codereview.chromium.org/2495413002/diff/40001/base/profiler/native_st...
File base/profiler/native_stack_sampler_win.cc (left):

https://codereview.chromium.org/2495413002/diff/40001/base/profiler/native_st...
base/profiler/native_stack_sampler_win.cc:356: std::memcpy(stack_copy_buffer,
reinterpret_cast<const void*>(bottom),
Can we keep this if !defined(ADDRESS_SANITIZER)? Standard libraries often
optimize memcpy in ways that compilers don’t for simple byte-at-a-time loops.

[etienneb, 2016-11-15 16:55:41]

Nico, any toughs?

https://codereview.chromium.org/2495413002/diff/40001/base/profiler/native_st...
File base/profiler/native_stack_sampler_win.cc (left):

https://codereview.chromium.org/2495413002/diff/40001/base/profiler/native_st...
base/profiler/native_stack_sampler_win.cc:356: std::memcpy(stack_copy_buffer,
reinterpret_cast<const void*>(bottom),
On 2016/11/15 16:52:04, Mark Mentovai wrote:
> Can we keep this if !defined(ADDRESS_SANITIZER)? Standard libraries often
> optimize memcpy in ways that compilers don’t for simple byte-at-a-time loops.

I'm not against it. Typically we try to avoid ifdef and duplicate code.
But, It's true that compilers may optimize memcpy and the stack profiler may be
CPU sensitive.

[Nico, 2016-11-15 16:56:47]

up to mark

On Tue, Nov 15, 2016 at 11:55 AM, <etienneb@chromium.org> wrote:

> Nico, any toughs?
>
>
> https://codereview.chromium.org/2495413002/diff/40001/
> base/profiler/native_stack_sampler_win.cc
> File base/profiler/native_stack_sampler_win.cc (left):
>
> https://codereview.chromium.org/2495413002/diff/40001/
> base/profiler/native_stack_sampler_win.cc#oldcode356
> base/profiler/native_stack_sampler_win.cc:356:
> std::memcpy(stack_copy_buffer, reinterpret_cast<const void*>(bottom),
> On 2016/11/15 16:52:04, Mark Mentovai wrote:
> > Can we keep this if !defined(ADDRESS_SANITIZER)? Standard libraries
> often
> > optimize memcpy in ways that compilers don’t for simple byte-at-a-time
> loops.
>
> I'm not against it. Typically we try to avoid ifdef and duplicate code.
> But, It's true that compilers may optimize memcpy and the stack profiler
> may be CPU sensitive.
>
> https://codereview.chromium.org/2495413002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2016-11-15 16:56:52]

Right. If it doesn’t actually run often, I don’t care. But the optimized
memcpy() is almost free, so if it does run frequently, it’d be nice to not
regress.

[etienneb, 2016-11-15 17:04:11]

fix applied

[Mark Mentovai, 2016-11-15 17:09:41]

LGTM

[etienneb, 2016-11-15 17:10:28]

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

[etienneb, 2016-11-15 17:10:45]

The CQ bit was unchecked by etienneb@chromium.org

[Mike Wittman, 2016-11-17 01:57:54]

lgtm % nit

On 2016/11/15 16:56:52, Mark Mentovai wrote:
> Right. If it doesn’t actually run often, I don’t care. But the optimized
> memcpy() is almost free, so if it does run frequently, it’d be nice to not
> regress.

We definitely want the CRT's optimized memcpy here, since the thread being
profiled is suspended until the copy completes.

https://codereview.chromium.org/2495413002/diff/80001/base/profiler/native_st...
File base/profiler/native_stack_sampler_win.cc (right):

https://codereview.chromium.org/2495413002/diff/80001/base/profiler/native_st...
base/profiler/native_stack_sampler_win.cc:356: #if defined(ADDRESS_SANITIZER)
nit: can we encapsulate this ifdef in its own function? This is the most
important block of code in the profiler and having the ifdef here detracts from
readability.

[etienneb, 2016-11-17 19:29:54]

Wittman, fine with this?

https://codereview.chromium.org/2495413002/diff/80001/base/profiler/native_st...
File base/profiler/native_stack_sampler_win.cc (right):

https://codereview.chromium.org/2495413002/diff/80001/base/profiler/native_st...
base/profiler/native_stack_sampler_win.cc:356: #if defined(ADDRESS_SANITIZER)
On 2016/11/17 01:57:54, Mike Wittman wrote:
> nit: can we encapsulate this ifdef in its own function? This is the most
> important block of code in the profiler and having the ifdef here detracts
from
> readability.

Done.

[Mike Wittman, 2016-11-17 19:32:50]

lgtm with another nit :)

Thanks!

https://codereview.chromium.org/2495413002/diff/100001/base/profiler/native_s...
File base/profiler/native_stack_sampler_win.cc (right):

https://codereview.chromium.org/2495413002/diff/100001/base/profiler/native_s...
base/profiler/native_stack_sampler_win.cc:369: base::CopyMemoryFromStack(
nit: no need for base::

[etienneb, 2016-11-17 19:35:03]

thanks

https://codereview.chromium.org/2495413002/diff/100001/base/profiler/native_s...
File base/profiler/native_stack_sampler_win.cc (right):

https://codereview.chromium.org/2495413002/diff/100001/base/profiler/native_s...
base/profiler/native_stack_sampler_win.cc:369: base::CopyMemoryFromStack(
On 2016/11/17 19:32:50, Mike Wittman wrote:
> nit: no need for base::

Done.

[etienneb, 2016-11-17 19:35:14]

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

[commit-bot: I haz the power, 2016-11-17 19:36:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-17 21:47:31]

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

[commit-bot: I haz the power, 2016-11-17 21:47:32]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)

[etienneb, 2016-11-18 16:23:32]

The CQ bit was checked by etienneb@chromium.org

[etienneb, 2016-11-18 16:23:32]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org,
rnk@chromium.org, mark@chromium.org, wittman@chromium.org
Link to the patchset: https://codereview.chromium.org/2495413002/#ps120001
(title: "nit")

[commit-bot: I haz the power, 2016-11-18 16:24:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-18 18:48:18]

Description was changed from

==========
Fix false-positive ASAN detection with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

to

==========
Fix false-positive ASAN detection with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

[commit-bot: I haz the power, 2016-11-18 18:48:19]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-11-18 18:51:35]

Description was changed from

==========
Fix false-positive ASAN detection with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41


R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829
==========

to

==========
Fix false-positive ASAN detection with the stack profiler on win64

The sampling profiler is triggering an ASAN error when instrumenting Chrome for
checking memory accesses on a windows 7 and windows 10 computer.

=================================================================
==14512==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x00000017dc20 at pc 0x00013fae1b45 bp 0x00000a70e940 sp 0x00000a70e958
READ of size 10816 at 0x00000017dc20 thread T2
    #0 0x13fae1b76 in __asan_memcpy
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:413
    #1 0x7fecf9224bf in base::`anonymous
namespace'::SuspendThreadAndRecordStack+0x21f
(D:\src\chromium\src\out\asan64dynamic\chrome.dll+0x1863f24bf)
    #2 0x7fecf921c8d in base::`anonymous
namespace'::NativeStackSamplerWin::RecordStackSample
D:\src\chromium\src\base\profiler\native_stack_sampler_win.cc:457

[...]

  This frame has 1 object(s):
    [32, 440) 'wsa_data.i.i.i.i.i' <== Memory access at offset 0 partially
underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind
mechanism or swapcontext
      (longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
d:\src\llvm\llvm\projects\compiler-rt\lib\asan\asan_interceptors.cc:41

R=wittman@chromium.org, mark@chromium.org, rnk@google.com, thakis@google.com

BUG=663829

Committed: https://crrev.com/4e9250a7663d37a3490b2aa936a0b634af518670
Cr-Commit-Position: refs/heads/master@{#433256}
==========

[commit-bot: I haz the power, 2016-11-18 18:51:37]

Patchset 7 (id:??) landed as
https://crrev.com/4e9250a7663d37a3490b2aa936a0b634af518670
Cr-Commit-Position: refs/heads/master@{#433256}