Crashing tests on Windows x64

[cmb69]

Description

As of 4dc7795, a couple of tests are crashing. (Note that the issues have no introduced by this commit, but are merely visible now.)

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #54268 (Double free when destroy_zend_class fails) [D:\a\php-src\php-src\Zend\tests\bug54268.phpt]
GH-9407: LSP error in eval'd code refers to wrong class for static type [D:\a\php-src\php-src\Zend\tests\gh9407.phpt]
Stack limit 014 - Fuzzer [D:\a\php-src\php-src\Zend\tests\stack_limit\stack_limit_014.phpt]
GH-14639 (Member access within null pointer in ext/spl/spl_observer.c) [D:\a\php-src\php-src\ext\spl\tests\gh14639.phpt]
Bug #45392 (ob_start()/ob_end_clean() and memory_limit) [D:\a\php-src\php-src\tests\lang\bug45392.phpt]
=====================================================================

4 of these test fail with status code FFFFFFFFC00000FF, which is ERROR_EA_LIST_INCONSISTENT, while one fails with FFFFFFFFC0000028, which is ERROR_OUT_OF_PAPER (these errors don't make much sense, but the German translation of ERROR_OUT_OF_PAPER even less: "Der Drucker ist aus Papier.")

Anyhow, this appears to be a tracing JIT issue.

PHP Version

master

Operating System

Windows

[cmb69]

Oops, apparently looked up the wrong error codes: FFFFFFFFC0000028 is STATUS_BAD_STACK and FFFFFFFFC00000FF is STATUS_BAD_FUNCTION_TABLE. Makes more sense.

Note that locally I can only reproduce the crashes of Zend\tests\gh9407.phpt and tests\lang\bug45392.phpt, and both fail with STATUS_BAD_STACK, but only with tracing JIT enabled. gh9407.phpt fails on the LONGJMP() in _zend_bailout().

[cmb69]

#14919 (comment) seems to be related.

PS: indeed, the tests are only failing when built with Visual Studio 2022 on x64 (but not on x86, and not when built with Visual Studio 2019). There might be an issue with vs17, or maybe just more thorough checking.

[iluuu1994]

Der Drucker ist aus Papier.

Lol. That sounds like it would be a problem.

[Girgias]

If/when this issue is fixed 6d59620 should be reverted.

[cmb69]

‎Zend/tests/gh16508.phpt has the same issue (STATUS_BAD_FUNCTION_TABLE). I cannot reproduce locally like for the other STATUS_BAD_FUNCTION_TABLE tests. I can only reproduce STATUS_BAD_STACK issues. I'll have a closer look.

[cmb69]

I've experimented with this locally, focusing on the Zend/tests/gh9407.phpt, since I can reproduce the STATUS_BAD_STACK reliably with x64/vs17 ZTS builds on master. I cannot, however, reproduce with x86 builds, nor NTS builds. nor with vs16, nor with vs17 builds of PHP-8.3. I also cannot reproduce if running gh9407.php. I've also did some experiments with CI. Some findings:

• On Windows (at least x64), longjmp() normally calls RtlUnwindEx() to unwind the stack frame by frame, rather than jumping directly to the address directly. There is a hack to work around that, and this made gh9407.phpt pass locally, but on CI it triggered lots of STATUS_FAIL_FAST_EXCEPTIONs (which I haven't been able to reproduce locally). Anyhow, circumventing RtlUnwindEx() would unlikely be a proper solution, since it would not call C++ destructors.
• At least with vs17, setjmp() calls __intrinsic_setjmp (what might explain that there are no issues with vs16; I haven't checked what vs16 compiles, though)
• Perhaps the stack backtrace at Update Windows CI to build with vs17 #14919 (comment) gives a hint; why does it start with zend_jit_trace_hot_root()? Maybe we need to have a look at https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64.

PS: the issue apparently does not occur if ZEND_DEBUG=1, and is likely somewhat related to ASan builds on Windows.

[danog]

Note that adding --repeat 2 and improving the JIT flags as per #12406 also creates a number of additional issues: https://github.com/danog/php-src/actions/runs/11869776299/job/33080469494#step:6:470