Use report_fatal_error before destroying input object on error.

Use report_fatal_error before destroying input object on error.

The input object may be a QueueStreamer, which the compile
server will still have a reference to (even though
downstream the memory object API and parser API thinks it
has a unique_ptr). Terminate the thread quickly on error,
instead of free'ing and causing a use-after-free.

Also set up a report_fatal_error handler which has access
to the server's state. This allows the server to record the
error and stop pushing bytes to the QueueStreamer.
Otherwise the QueueStreamer can get full without a consumer
still active to unblock.

Unfortunately the fatal error handler only terminates the
current thread, and not all worker threads. NaCl doesn't
have support for signals or pthread_kill.
E.g., with pthread_kill(std_thread.native_handle(), SIGABRT).
So, other worker/emitter threads will have to hang waiting on
more input or something.

Random clang-format edits from 3.7.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=4163
TEST= tbd:

I manually ran the translator a dummy text file (invalid bitcode
header), and observed that this no longer crashes. Instead the SRPC
calls finish and I see:

3> [17812,4147750656:14:23:02.025382] Streaming file at 100000 bps
[17812,4147750656:14:23:12.511574] RPC call failed: Rpc application returned an error.
[17812,4147750656:14:23:12.511625] StreamChunk failed
[17812,4147750656:14:23:12.511655] stream_file: SendDataChunk failed, but returning without failing. Expect call to StreamEnd.4> rpc call initiated StreamEnd::isss
[17812,4147750656:14:23:12.511931] RPC call failed: Rpc application returned an error.
rpc call complete StreamEnd::isss
output 0:  i(0)
output 1:  s("")
output 2:  s("")
output 3:  s("Invalid PNaCl bitcode header")
[17812,4147750656:14:23:12.512102] Command [rpc] failed.

R=kschimpf@google.com, stichnot@chromium.org

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=2f7f2b7e17a1ec338df337c806af657c4ed2cd8e

[jvoung (off chromium), 2015-06-02 21:30:38]

jvoung@chromium.org changed reviewers:
+ dschuff@chromium.org, kschimpf@google.com, stichnot@chromium.org

[Jim Stichnoth, 2015-06-03 16:16:01]

lgtm

https://codereview.chromium.org/1168543002/diff/1/src/IceBrowserCompileServer...
File src/IceBrowserCompileServer.cpp (right):

https://codereview.chromium.org/1168543002/diff/1/src/IceBrowserCompileServer...
src/IceBrowserCompileServer.cpp:157: Ctx->getStrError() << Reason;
I was wondering about using OstreamLocker for multithreading safety/consistency,
but I guess that would be bad if an error were thrown while the lock was already
being held.

[Karl, 2015-06-03 16:27:16]

lgtm

[jvoung (off chromium), 2015-06-04 00:33:16]

https://codereview.chromium.org/1168543002/diff/1/src/IceBrowserCompileServer...
File src/IceBrowserCompileServer.cpp (right):

https://codereview.chromium.org/1168543002/diff/1/src/IceBrowserCompileServer...
src/IceBrowserCompileServer.cpp:157: Ctx->getStrError() << Reason;
On 2015/06/03 16:16:01, stichnot wrote:
> I was wondering about using OstreamLocker for multithreading
safety/consistency,
> but I guess that would be bad if an error were thrown while the lock was
already
> being held.

Hmm good point. I forgot about OstreamLocker, but yeah it would be bad to
deadlock here.

E.g., if the code in
https://codereview.chromium.org/1168543002/diff/1/src/PNaClTranslator.cpp, had
acquired OstreamLocker and then called report_fatal_error (also forgot to get
OstreamLocker there).

[jvoung (off chromium), 2015-06-04 00:50:27]

Committed patchset #1 (id:1) manually as
2f7f2b7e17a1ec338df337c806af657c4ed2cd8e (tree was closed).