Add flush to output to try to diagnose locks failure

Add flush to output to try to diagnose locks failure

end_to_end_test.py started failing after landing
https://codereview.chromium.org/1392093003/ but I'm not sure why. It
seems
https://build.chromium.org/p/client.crashpad/builders/crashpad_win_x64_dbg/builds/45/steps/run%20tests/logs/stdio
to be aborting in a place that doesn't make much sense, so try adding
flushes to see if there's output getting lost.

R=mark@chromium.org

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/71cc0a28a4960ba050c0be05b36b870df9d20348

[Mark Mentovai, 2015-10-15 22:00:08]

LGTM

[scottmg, 2015-10-15 22:03:27]

Committed patchset #2 (id:20001) manually as
71cc0a28a4960ba050c0be05b36b870df9d20348 (presubmit successful).

[scottmg, 2015-10-15 22:10:12]

Well.

https://build.chromium.org/p/client.crashpad/builders/crashpad_win_x86_wow64_...

1) I am glad we have this test;
2) I have no idea what the matter is;
3) I am annoyed that sys.stderr isn't autoflush.

[scottmg, 2015-10-15 22:30:14]

On 2015/10/15 22:10:12, scottmg wrote:
> Well.
> 
>
https://build.chromium.org/p/client.crashpad/builders/crashpad_win_x86_wow64_...
> 
> 1) I am glad we have this test;
> 2) I have no idea what the matter is;
> 3) I am annoyed that sys.stderr isn't autoflush.

Oh, it's in crashy_program of course. Hmm, it'll need to communicate that it
can't allocate with DEBUG_INFO back to this test.

[Mark Mentovai, 2015-10-15 22:33:08]

The fact that it couldn’t do that at all is also troubling.