Fix OSS-Fuzz #447521098

[nielsdos]

There are exit points (via bailout) in this function that do not free the recorded errors. This can cause issues when an error is emitted during shutdown as ZendMM will have shut down already but the pointer is still pointing to ZendMM memory.

This became visible after 7b3e68f

We also need to backport part of this patch to handle signal unblocking and opcache memory protection, otherwise we get issues (and errors about depth level in zend_signals).

[arnaud-lb]

I think this may also happen with the opcache_compile_file(file_handle, type, &op_array); call above

[nielsdos]

I think this may also happen with the opcache_compile_file(file_handle, type, &op_array); call above

Hmm none of the calls to opcache_compile_file surround it with a try-catch. I suppose you may be right but I need to think a bit about it.

[arnaud-lb]

Ah, I likely was wrong about opcache_compile_file: it handles bailouts itself

[nielsdos]

@arnaud-lb @iluuu1994 It appears that 16a8591 fixed this already, although I wonder if there are other bailout opportunities.

[iluuu1994]

16a8591 was necessary regardless, as the code was wrong. From what I understand, the optimizer tries to avoid bailout with the zend_binary_op_produces_error() and friends functions. This is pretty fragile, so maybe there's a better, more general solution.

[arnaud-lb]

The fact that cache_script_in_shared_memory() runs under HANDLE_BLOCK_INTERRUPTIONS() / SHM_UNPROTECT(), which mandates that this should be reverted in case of bailout, but was not wrapped in try-catch before, confirms that it is not supposed to bailout.

[nielsdos]

Ack