Copy the thread name to the stack for debugging purposes.

Copy the thread name to the stack for debugging purposes.

The this ptr in Thread is getting smashed after the MessageLoop ends, which
leaves very little to go on. This is kind of a stab in the dark, but hopefully
it makes something bleed in a general direction.

BUG=274705
TEST=Minidumps contain 47 bytes of thread name data way high on the stack.
R=mark@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=222826

[Mark Mentovai, 2013-09-12 18:38:37]

https://codereview.chromium.org/23606030/diff/1/base/threading/thread.cc
File base/threading/thread.cc (right):

https://codereview.chromium.org/23606030/diff/1/base/threading/thread.cc#newc...
base/threading/thread.cc:178: // the minidump stack dump.
If you’re trying to make it easier to find in a minidump, you probably also want
to zero out unused bytes so that they don’t look like garbage.

https://codereview.chromium.org/23606030/diff/1/base/threading/thread.cc#newc...
base/threading/thread.cc:184: thread_name[kThreadNameSize - 3] = '\3';
How are you assuring that storage for variable, unused after this point, won’t
be recycled for other purposes by an optimizing compiler? For that matter, the
compiler may have sufficient intelligence to reason that this code is all
side-effect-free and completely optimize it out entirely.

[Robert Sesek, 2013-09-12 18:47:53]

https://codereview.chromium.org/23606030/diff/1/base/threading/thread.cc
File base/threading/thread.cc (right):

https://codereview.chromium.org/23606030/diff/1/base/threading/thread.cc#newc...
base/threading/thread.cc:178: // the minidump stack dump.
On 2013/09/12 18:38:37, Mark Mentovai wrote:
> If you’re trying to make it easier to find in a minidump, you probably also
want
> to zero out unused bytes so that they don’t look like garbage.

If strlen(s2) < n, then it fills the remainder with \0. But I {0} it for you.

https://codereview.chromium.org/23606030/diff/1/base/threading/thread.cc#newc...
base/threading/thread.cc:184: thread_name[kThreadNameSize - 3] = '\3';
On 2013/09/12 18:38:37, Mark Mentovai wrote:
> How are you assuring that storage for variable, unused after this point, won’t
> be recycled for other purposes by an optimizing compiler? For that matter, the
> compiler may have sufficient intelligence to reason that this code is all
> side-effect-free and completely optimize it out entirely.

Good point. Using base::debug::Alias() now at the top and bottom of this scope.

[Mark Mentovai, 2013-09-12 18:52:18]

LGTM

https://codereview.chromium.org/23606030/diff/9001/base/threading/thread.cc
File base/threading/thread.cc (right):

https://codereview.chromium.org/23606030/diff/9001/base/threading/thread.cc#n...
base/threading/thread.cc:181: char thread_name[kThreadNameSize] = { 0 };
Oh, you’re using strncpy, OK, you can get rid of this. I was thinking snprintf,
which is what I usually use when I’m unsure about overflow, since it portably
guarantees NUL-termination.

[Robert Sesek, 2013-09-12 18:55:26]

Committed patchset #3 manually as r222826 (presubmit successful).