Make crash reporting client_id accessible through child_process_logging.

Make crash reporting client_id accessible through child_process_logging.

On Mac and Linux, keep the client id in a global variable kept by the
child_process_logging implementations. This allows to read it in a
thread safe fashion when starting a child process.

Also replace std::string with statically allocated buffers for the
various items we add to the crash reports. This allows to properly
handle crashes upon shutdown (std::string would run its destructor,
invalidating the memory).

BUG=53231
TEST=Crash reporting should still work

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=57497

[Mattias Nissler (ping if slow), 2010-08-24 19:28:02]

Hi, here are some crash reporter changes. I'm not sure whether the global
variables approach is the right one, can you take a look and advise? Thanks.

[Lei Zhang, 2010-08-24 21:05:25]

I imagine the strings holding these values are destroyed pretty late in the
shutdown process, so we probably don't gain that much from converting them to
char[], but I don't have a problem with using char[] either.

http://codereview.chromium.org/3186028/diff/1/4
File chrome/app/breakpad_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/4#newcode682
chrome/app/breakpad_linux.cc:682: kMaxActiveURLSize);
nit: this fits on the previous line.

http://codereview.chromium.org/3186028/diff/1/7
File chrome/common/child_process_logging_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/7#newcode25
chrome/common/child_process_logging_linux.cc:25: static void CopyToBuffer(const
std::string& str, char* buffer, size_t len) {
Would it be more efficient to do the following?

size_t str_length = std::min(str.length(), len);
str.copy(buffer, str_length);
buffer[str_length] = '\0';

http://codereview.chromium.org/3186028/diff/1/8
File chrome/common/child_process_logging_mac.mm (right):

http://codereview.chromium.org/3186028/diff/1/8#newcode32
chrome/common/child_process_logging_mac.mm:32: static char
g_client_id[kClientIdSize + 1] = "";
I don't know if this is needed on Mac. Perhaps the code should look more like
the Windows code? Mark can probably tell you what's right for Mac.

[Mark Mentovai, 2010-08-24 21:22:22]

http://codereview.chromium.org/3186028/diff/1/3
File base/linux_util.h (right):

http://codereview.chromium.org/3186028/diff/1/3#newcode1
base/linux_util.h:1: // Copyright (c) 2010 The Chromium Authors. All rights
reserved.
Why don’t you put the declaration of g_linux_distro in this file? Expecting
consumers to declare an extern themselves sucks.

http://codereview.chromium.org/3186028/diff/1/4
File chrome/app/breakpad_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/4#newcode589
chrome/app/breakpad_linux.cc:589: // These are defined in
chrome/common/child_process_logging_linux.cc. These
Again, what’s up with this? Just declare the externs in the appropriate .h.

http://codereview.chromium.org/3186028/diff/1/7
File chrome/common/child_process_logging_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/7#newcode25
chrome/common/child_process_logging_linux.cc:25: static void CopyToBuffer(const
std::string& str, char* buffer, size_t len) {
Lei Zhang wrote:
> Would it be more efficient to do the following?
> 
> size_t str_length = std::min(str.length(), len);
> str.copy(buffer, str_length);
> buffer[str_length] = '\0';

This memset + std::string::copy pattern appears all over this change. I don’t
love it either. I prefer what Lei proposes. Be sure that whatever you do, you
make it nice throughout the change, not just in this location.

http://codereview.chromium.org/3186028/diff/1/8
File chrome/common/child_process_logging_mac.mm (right):

http://codereview.chromium.org/3186028/diff/1/8#newcode111
chrome/common/child_process_logging_mac.mm:111: *client_id = g_client_id;
If the setter uses GoogleUpdateSettings::SetMetricsId, why wouldn’t the getter
be able to use GetMetricsId?

I guess the same question even applies to the Linux version.

The wstring and conversion suck, but that applies to the Windows version as you
have it now.

It kind of seems like there might be a way to have a platform-neutral getter
here, and at least a portion of the setter can be platform-neutral too.

[Lei Zhang, 2010-08-24 21:28:03]

http://codereview.chromium.org/3186028/diff/1/8
File chrome/common/child_process_logging_mac.mm (right):

http://codereview.chromium.org/3186028/diff/1/8#newcode111
chrome/common/child_process_logging_mac.mm:111: *client_id = g_client_id;
On 2010/08/24 21:22:22, Mark Mentovai wrote:
> If the setter uses GoogleUpdateSettings::SetMetricsId, why wouldn’t the getter
> be able to use GetMetricsId?
> 
> I guess the same question even applies to the Linux version.
> 
> The wstring and conversion suck, but that applies to the Windows version as
you
> have it now.
> 
> It kind of seems like there might be a way to have a platform-neutral getter
> here, and at least a portion of the setter can be platform-neutral too.

I don't know if there's any restrictions on Win/Mac, but the Linux Breakpad code
that consumes the client id / Linux distro string is in a compromised context
that cannot call into libc / allocate memory. Thus for Linux, we hold the data
in a string and read it directly.

[Mark Mentovai, 2010-08-24 21:39:23]

[email protected] wrote:
> I don't know if there's any restrictions on Win/Mac, but the Linux
> Breakpad code that consumes the client id / Linux distro string is in a
> compromised context that cannot call into libc / allocate memory. Thus
> for Linux, we hold the data in a string and read it directly.

OK, I see.

Mac and Linux share the same implementation here. See
chrome/browser/google_update_settings_posix.cc. It provides no getter.

Could it? Yes. But the posix_guid field that it stores should be
converted to a char[] in that case. (Keep pulling the thread, right?)

The nice thing about that is that it would unify a tiny bit more of
the “common” code. Having common POSIX code for Mac and Linux where
they need to share is better than writing the same thing twice.

Mark

[Mattias Nissler (ping if slow), 2010-08-24 22:31:23]

Thanks for your feedback, I've put some more thoughts/explanations.

Lei: Regarding the std::string dtor, I currently see a Linux crash on shutdown
on my machine (didn't investigate yet what it is exactly) that indeed does
happen after the string gets destroyed, so I thought that's enough of a reason
to correctly handle that case.

Mark: Please check my comment regarding the GoogleUpdateSettings changes, I
think the situation is a bit more involved and implementing GetMetricsId() in
google_update_settings_posix.cc won't solve all problems.

http://codereview.chromium.org/3186028/diff/1/3
File base/linux_util.h (right):

http://codereview.chromium.org/3186028/diff/1/3#newcode1
base/linux_util.h:1: // Copyright (c) 2010 The Chromium Authors. All rights
reserved.
On 2010/08/24 21:22:22, Mark Mentovai wrote:
> Why don’t you put the declaration of g_linux_distro in this file? Expecting
> consumers to declare an extern themselves sucks.

I agree with you. I've found it that way and tried to only make gentle
adjustments, but I'm happy to do a more thorough cleanup.

http://codereview.chromium.org/3186028/diff/1/7
File chrome/common/child_process_logging_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/7#newcode25
chrome/common/child_process_logging_linux.cc:25: static void CopyToBuffer(const
std::string& str, char* buffer, size_t len) {
On 2010/08/24 21:22:22, Mark Mentovai wrote:
> Lei Zhang wrote:
> > Would it be more efficient to do the following?
> > 
> > size_t str_length = std::min(str.length(), len);
> > str.copy(buffer, str_length);
> > buffer[str_length] = '\0';
> 
> This memset + std::string::copy pattern appears all over this change. I don’t
> love it either. I prefer what Lei proposes. Be sure that whatever you do, you
> make it nice throughout the change, not just in this location.

I agree this pattern is not very nice. My reason for putting the initial memset
was to ensure the string is always terminated, even if we crash while writing to
it (on a different thread). Otherwise, the crash reporting code might fail, no?

http://codereview.chromium.org/3186028/diff/1/8
File chrome/common/child_process_logging_mac.mm (right):

http://codereview.chromium.org/3186028/diff/1/8#newcode111
chrome/common/child_process_logging_mac.mm:111: *client_id = g_client_id;
On 2010/08/24 21:28:04, Lei Zhang wrote:
> On 2010/08/24 21:22:22, Mark Mentovai wrote:
> > If the setter uses GoogleUpdateSettings::SetMetricsId, why wouldn’t the
getter
> > be able to use GetMetricsId?
> > 
> > I guess the same question even applies to the Linux version.
> > 
> > The wstring and conversion suck, but that applies to the Windows version as
> you
> > have it now.
> > 
> > It kind of seems like there might be a way to have a platform-neutral getter
> > here, and at least a portion of the setter can be platform-neutral too.
> 
> I don't know if there's any restrictions on Win/Mac, but the Linux Breakpad
code
> that consumes the client id / Linux distro string is in a compromised context
> that cannot call into libc / allocate memory. Thus for Linux, we hold the data
> in a string and read it directly.

I think we don't need it on Mac, will recheck and adjust tomorrow.

http://codereview.chromium.org/3186028/diff/1/8#newcode111
chrome/common/child_process_logging_mac.mm:111: *client_id = g_client_id;
On 2010/08/24 21:22:22, Mark Mentovai wrote:
> If the setter uses GoogleUpdateSettings::SetMetricsId, why wouldn’t the getter
> be able to use GetMetricsId?
> 
> I guess the same question even applies to the Linux version.
> 
> The wstring and conversion suck, but that applies to the Windows version as
you
> have it now.
> 
> It kind of seems like there might be a way to have a platform-neutral getter
> here, and at least a portion of the setter can be platform-neutral too.

The thing with GoogleUpdateSettings is that it is basically an interface to a
backing text file on Mac and Linux. It can happen that we don't have the file,
but nevertheless want to do crash reporting and use the client ID (which is
stored in the local state prefs file). That is the case when crash reporting is
force-enabled through configuration policy but the user never explicitly stated
their "Consent to Send Stats". So if we want to build on GoogleUpdateSettings,
we'll need to modify the logic there to update posix_guid without writing the
file etc.  I thought keeping everything one layer above GoogleUpdateSettings
would make the whole thing more understandable.

[Mark Mentovai, 2010-08-25 00:20:14]

[email protected] wrote:
> I agree this pattern is not very nice. My reason for putting the initial
> memset was to ensure the string is always terminated, even if we crash
> while writing to it (on a different thread). Otherwise, the crash
> reporting code might fail, no?

You can terminate the string before you copy to your fixed buffer if
you’re ultra-paranoid, you don’t need to memset the entire buffer.
Even so, that shouldn’t be necessary. The way the code is currently
structured, if you have static const size_t l, and static char s[l +
1], you’re always guaranteed that s[l] == '\0'.

(More tomorrow.)

Mark

[Mattias Nissler (ping if slow), 2010-08-25 10:36:44]

Here's a new version that addresses most of the feedback.

http://codereview.chromium.org/3186028/diff/1/3
File base/linux_util.h (right):

http://codereview.chromium.org/3186028/diff/1/3#newcode1
base/linux_util.h:1: // Copyright (c) 2010 The Chromium Authors. All rights
reserved.
On 2010/08/24 22:31:23, mnissler wrote:
> On 2010/08/24 21:22:22, Mark Mentovai wrote:
> > Why don’t you put the declaration of g_linux_distro in this file? Expecting
> > consumers to declare an extern themselves sucks.
> 
> I agree with you. I've found it that way and tried to only make gentle
> adjustments, but I'm happy to do a more thorough cleanup.

Done.

http://codereview.chromium.org/3186028/diff/1/4
File chrome/app/breakpad_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/4#newcode589
chrome/app/breakpad_linux.cc:589: // These are defined in
chrome/common/child_process_logging_linux.cc. These
On 2010/08/24 21:22:22, Mark Mentovai wrote:
> Again, what’s up with this? Just declare the externs in the appropriate .h.

Done.

http://codereview.chromium.org/3186028/diff/1/4#newcode682
chrome/app/breakpad_linux.cc:682: kMaxActiveURLSize);
On 2010/08/24 21:05:25, Lei Zhang wrote:
> nit: this fits on the previous line.

You mean the kMaxActiveURLSize? It doesn't.

http://codereview.chromium.org/3186028/diff/1/7
File chrome/common/child_process_logging_linux.cc (right):

http://codereview.chromium.org/3186028/diff/1/7#newcode25
chrome/common/child_process_logging_linux.cc:25: static void CopyToBuffer(const
std::string& str, char* buffer, size_t len) {
On 2010/08/24 22:31:23, mnissler wrote:
> On 2010/08/24 21:22:22, Mark Mentovai wrote:
> > Lei Zhang wrote:
> > > Would it be more efficient to do the following?
> > > 
> > > size_t str_length = std::min(str.length(), len);
> > > str.copy(buffer, str_length);
> > > buffer[str_length] = '\0';
> > 
> > This memset + std::string::copy pattern appears all over this change. I
don’t
> > love it either. I prefer what Lei proposes. Be sure that whatever you do,
you
> > make it nice throughout the change, not just in this location.
> 
> I agree this pattern is not very nice. My reason for putting the initial
memset
> was to ensure the string is always terminated, even if we crash while writing
to
> it (on a different thread). Otherwise, the crash reporting code might fail,
no?

Ok, so I replace all of these now with copy-and-terminate. That relies on the
buffers being zero-initialized on startup so we always have a terminating null
byte, which is fine.

http://codereview.chromium.org/3186028/diff/1/8
File chrome/common/child_process_logging_mac.mm (right):

http://codereview.chromium.org/3186028/diff/1/8#newcode32
chrome/common/child_process_logging_mac.mm:32: static char
g_client_id[kClientIdSize + 1] = "";
On 2010/08/24 21:05:25, Lei Zhang wrote:
> I don't know if this is needed on Mac. Perhaps the code should look more like
> the Windows code? Mark can probably tell you what's right for Mac.

Replaced it with a std::string.

[Mark Mentovai, 2010-08-25 14:12:01]

[email protected] wrote:
>> I don't know if this is needed on Mac. Perhaps the code should look more like
>> the Windows code? Mark can probably tell you what's right for Mac.
>
> Replaced it with a std::string.

Put it back to a char[]. (Sorry for the runaround, I should have
mentioned that I didn’t agree with Lei’s opposition to char[].)

http://www.chromium.org/developers/coding-style#Static_Variables

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Static...

Mark

[Mattias Nissler (ping if slow), 2010-08-25 14:28:44]

On 2010/08/25 14:12:01, Mark Mentovai wrote:
> mailto:[email protected] wrote:
> >> I don't know if this is needed on Mac. Perhaps the code should look more
like
> >> the Windows code? Mark can probably tell you what's right for Mac.
> >
> > Replaced it with a std::string.
> 
> Put it back to a char[]. (Sorry for the runaround, I should have
> mentioned that I didn’t agree with Lei’s opposition to char[].)
> 
> http://www.chromium.org/developers/coding-style#Static_Variables
> 
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Static...

Right. Sorry for making that change in the first place, I think what Lei was
getting at is to pull the value from GoogleUpdateSettings, which I've commented
on already.

[Mark Mentovai, 2010-08-25 14:43:10]

LG with these changes.

http://codereview.chromium.org/3186028/diff/16001/17002
File base/linux_util.h (right):

http://codereview.chromium.org/3186028/diff/16001/17002#newcode19
base/linux_util.h:19: // in compromised context without going to through the
standard library.
“to through” transposed.

http://codereview.chromium.org/3186028/diff/16001/17005
File chrome/common/child_process_logging.h (right):

http://codereview.chromium.org/3186028/diff/16001/17005#newcode42
chrome/common/child_process_logging.h:42: void GetClientId(std::string*
client_id);
This should return a std::string instead of doing the out-parameter thing.

[Mattias Nissler (ping if slow), 2010-08-25 15:12:42]

Ok, here's an update. Waiting for thumbs up from Lei.

http://codereview.chromium.org/3186028/diff/16001/17002
File base/linux_util.h (right):

http://codereview.chromium.org/3186028/diff/16001/17002#newcode19
base/linux_util.h:19: // in compromised context without going to through the
standard library.
On 2010/08/25 14:43:10, Mark Mentovai wrote:
> “to through” transposed.

Done.

http://codereview.chromium.org/3186028/diff/16001/17005
File chrome/common/child_process_logging.h (right):

http://codereview.chromium.org/3186028/diff/16001/17005#newcode42
chrome/common/child_process_logging.h:42: void GetClientId(std::string*
client_id);
On 2010/08/25 14:43:10, Mark Mentovai wrote:
> This should return a std::string instead of doing the out-parameter thing.

Done.

[Lei Zhang, 2010-08-25 18:24:42]

Being 3 timezones behind Mark, this looks like the right time for a LGTM.