Fix bug #77653 (operator displayed instead of the real error message)

[bukka]

Fix for https://bugs.php.net/bug.php?id=77653 . It's #4007 rebased on 7.4.

[nikic]

It's been a while since I last looked at this, so I've forgotten some of the context for this change...

I don't quite get why we need \0fscf as the flush command, wouldn't using \n work as well? It seems like the handling for both is basically the same (zlog_stream_str + zlog_stream_finish), just simpler for \n because it's a single character.

[bukka]

I don't quite get why we need \0fscf as the flush command, wouldn't using \n work as well? It seems like the handling for both is basically the same (zlog_stream_str + zlog_stream_finish), just simpler for \n because it's a single character.

@nikic It's because \n would add an extra new line to the logs. Basically \0fscf is noop if there isn't anything in the buffer but \n would add an extra new line which wouldn't be probably nice as it happens after each request...

[bukka]

Merged as ee05793

[nikic]

I think after this change we are seeing intermittent failures like this:

========DIFF========
001+ ERROR: Unexpected line: [24-Feb-2020 11:10:01] NOTICE: Terminating ...
002+
========DONE========
FAIL FPM: Buffered worker output decorated log with msg containing new lines [sapi/fpm/tests/log-bwd-msg-with-nl.phpt] 

[nikic]

I think that's because there is a race condition now: Previously (I think) we first flushed stdio and then closed the body stream. Now we do it the other way around. This means that we may have either:

1. tester receives full response body
2. worker flushes stdio
3. tester issues terminate

or

1. tester received full response body
2. tester issues terminate
3. worker flushes stdio

Because of this, we may see log messages in both orders.

Do you know what we can do against this? It's causing a lot of CI failures.