Separate the "hello" message from the parameter messages in

Inspector::ReadMessages as was done before r627. The "hello" message contains
the parameter count and is referenced while the message reader loops through
parameter messages. Prior to r627, both messages were named |message|, which
was confusing, probably caused a compiler warning, and apparently provided the
motivation to share them. This caused the crash inspector to fail to properly
collect the parameters. The common failure mode (although others are possible)
was for the inspector to attempt tor read more parameter messages than were
available, resulting in an IPC timeout and inspector death. No crash report
would be written, and the application expecting its crash to be inspected
would time out waiting for a response from the inspector and then _exit. This
is effectively a failure to properly handle crashes.

The inner message is reintroduced, and named parameter_message for
disambiguation.

BUG=chromium:49821
TEST=Crashes catchable by the Mac Breakpad framework
Review URL: http://breakpad.appspot.com/123002

git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@628 4c0a9323-5329-0410-9bdc-e9ce6186880e
This commit is contained in:
mark@chromium.org 2010-07-21 21:21:07 +00:00
parent 4ac61acb3a
commit 615d2c0d6d

View file

@ -331,11 +331,12 @@ kern_return_t Inspector::ReadMessages() {
// we are expected to read.
// Read each key/value pair, one mach message per key/value pair.
for (unsigned int i = 0; i < info.parameter_count; ++i) {
result = receive_port.WaitForMessage(&message, 1000);
MachReceiveMessage parameter_message;
result = receive_port.WaitForMessage(&parameter_message, 1000);
if(result == KERN_SUCCESS) {
KeyValueMessageData &key_value_data =
(KeyValueMessageData&)*message.GetData();
(KeyValueMessageData&)*parameter_message.GetData();
// If we get a blank key, make sure we don't increment the
// parameter count; in some cases (notably on-demand generation
// many times in a short period of time) caused the Mach IPC