[lazerg]

zend_execute_script() only handled a pending delayed OOM when compilation produced an op_array, so a script that hit memory_limit while compiling and then failed with a parse error reported only the parse error. The OOM is now handled in the failure path too, dropping the pending ParseError so the memory error is the one reported.

Fixes GH-24631

[pentolope]

@lazerg I'd check that sapi/fuzzer/fuzzer-sapi.c is or gets fixed as well; it is the same pattern.

[lazerg]

Good catch, fuzzer-sapi.c had the same gap: the delayed OOM was only handled when compilation succeeded. I added the same handling for the failed-compile case in e305af1.

[ndossche]

This is slightly incomplete as zend_eval_stringl and php_lint_script need handling too.

[ndossche]

The zend_clear_exception call is necessary, but depends on the assumption that extensions handle clearing properly. As we now know, fiber and spl did not. The fix for fiber is underway, for spl there's an open PR.
Checking for ZEND_OOM_STATE_PENDING rather than ZEND_HAS_OOM is probably better as a defensive measure (same below)

[lazerg]

I switched all the new checks to ZEND_OOM_STATE_PENDING in 631a3b8, so an OOM that was already handled no longer clears an unrelated exception.

[lazerg]

@ndossche I added the same handling to zend_eval_stringl() and php_lint_script() in 631a3b8, with tests for php -r and php -l. php -l also lost the OOM when the file compiled without errors, so the lint check covers that case too.

[ndossche]

Please see my tiny remark and please drop the NEWS change so CI can run

[ndossche]

You don't need this line

[lazerg]

It is needed: zend_handle_delayed_oom() bails out here, so without it php -l on a valid file prints "No syntax errors detected" after the fatal error and oom_compile_failure_lint.phpt fails. I dropped the NEWS change.