Roll Breakpad to @970

Roll Breakpad to @970.
Add two NULL parameters to CrashGenerationServer ctor to match the new prototype (changed in r952)
Add the files appeared in r945 to breakpad.gyp

BUG=127776, 132164
TEST=remoting_unittests.BreakpadWinDeathTest.*

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

[alexeypa (please no reviews), 2012-06-12 22:24:06]

Please take a look.

[Mark Mentovai, 2012-06-12 22:30:43]

I don’t know about the current Breakpad trunk’s suitability for Chromium. I
can’t LG this as-is without making the inquiry. glider@chromium.org was
responsible for the previous two roll attempts, and he may know more.

https://chromiumcodereview.appspot.com/10544121/diff/1/DEPS
File DEPS (right):

https://chromiumcodereview.appspot.com/10544121/diff/1/DEPS#newcode71
DEPS:71: (Var("googlecode_url") % "google-breakpad") + "/trunk/src@970",
Previously, Breakpad was rolled to r963 at Chrome r136762. That was subsequently
reverted at r136925 with the message "symupload got broken.” Prior to that, we
tried a roll to r963 at r136558, and it got reverted at r136568 with the message
“compilation issues on Win.”

You should also check https://chromiumcodereview.appspot.com/10377108/, which
made other changes when rolling Breakpad.

[alexeypa (please no reviews), 2012-06-12 22:56:04]

Alexander,

Could you cast if bit of light on symupload problem caused by
https://chromiumcodereview.appspot.com/10544121? Thanks.

[Alexander Potapenko, 2012-06-13 01:42:59]

The problem is caused by a patch that I've made to Breakpad a month or so ago.
I've made it possible to send multiple files in a single multipart
request, but due to a subtle bug the multipart boundary got duplicated
when sending a single file (e.g. in symupload), which led to
server-side errors.

This should be fairly easy to fix, but I didn't have enough cycles for
it yet (the main problem is to test that it is still possible to send
several files). I'm on a conference till the EOW and can get back to
this next week. If it's urgent for you to roll the new Breakpad
revision, I'd suggest to revert my patch
(http://code.google.com/p/google-breakpad/source/detail?r=963) and
roll the DEPS.

On Wed, Jun 13, 2012 at 2:56 AM,  <alexeypa@chromium.org> wrote:
> Alexander,
>
> Could you cast if bit of light on symupload problem caused by
> https://chromiumcodereview.appspot.com/10544121? Thanks.
>
> https://chromiumcodereview.appspot.com/10544121/



-- 
Alexander Potapenko
Software Engineer
Google Moscow

[alexeypa (please no reviews), 2012-06-13 17:16:02]

On 2012/06/13 01:42:59, Alexander Potapenko wrote:
> The problem is caused by a patch that I've made to Breakpad a month or so ago.
> I've made it possible to send multiple files in a single multipart
> request, but due to a subtle bug the multipart boundary got duplicated
> when sending a single file (e.g. in symupload), which led to
> server-side errors.

> This should be fairly easy to fix, but I didn't have enough cycles for
> it yet (the main problem is to test that it is still possible to send
> several files).

This was fixed by @965, I believe. See https://breakpad.appspot.com/390002

[Alexander Potapenko, 2012-06-13 17:21:11]

On Wed, Jun 13, 2012 at 9:16 PM,  <alexeypa@chromium.org> wrote:
> On 2012/06/13 01:42:59, Alexander Potapenko wrote:
>>
>> The problem is caused by a patch that I've made to Breakpad a month or so
>> ago.
>> I've made it possible to send multiple files in a single multipart
>> request, but due to a subtle bug the multipart boundary got duplicated
>> when sending a single file (e.g. in symupload), which led to
>> server-side errors.
>
>
>> This should be fairly easy to fix, but I didn't have enough cycles for
>> it yet (the main problem is to test that it is still possible to send
>> several files).
>
>
> This was fixed by @965, I believe. See https://breakpad.appspot.com/390002

Looks like you're right.
Then I think it should be ok to roll Breakpad again.
You may want to notify dharani@ about the change for her to be heads up.

[Mark Mentovai, 2012-06-13 19:04:12]

https://chromiumcodereview.appspot.com/10544121/diff/1003/remoting/base/break...
File remoting/base/breakpad_win_unittest.cc (right):

https://chromiumcodereview.appspot.com/10544121/diff/1003/remoting/base/break...
remoting/base/breakpad_win_unittest.cc:92: NULL, 0,
All of the zeroes in this statement should be NULL instead.

[alexeypa (please no reviews), 2012-06-14 16:13:57]

https://chromiumcodereview.appspot.com/10544121/diff/1003/remoting/base/break...
File remoting/base/breakpad_win_unittest.cc (right):

https://chromiumcodereview.appspot.com/10544121/diff/1003/remoting/base/break...
remoting/base/breakpad_win_unittest.cc:92: NULL, 0,
On 2012/06/13 19:04:13, Mark Mentovai wrote:
> All of the zeroes in this statement should be NULL instead.

Done.

[Mark Mentovai, 2012-06-14 16:21:39]

LGTM

Big rolls like this are a little scary, so be sure to keep your eyes on
everything. Make sure that tomorrow’s canaries behave properly: that we get
crash reports from them, and that the symbols are correct.

[commit-bot: I haz the power, 2012-06-14 18:05:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexeypa@chromium.org/10544121/11001

[commit-bot: I haz the power, 2012-06-14 19:44:24]

Change committed as 142200

[Alexander Potapenko, 2012-06-18 18:22:48]

How did the roll go? Does symupload work for Mac Official now?

[alexeypa (please no reviews), 2012-06-18 20:58:36]

On 2012/06/18 18:22:48, Alexander Potapenko wrote:
> How did the roll go? Does symupload work for Mac Official now?

I've discussed this offline. The summary is "everything seems to be fine after
the roll".