Open cmb69 opened 3 months ago
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()
.
https://github.com/php/php-src/pull/14919#issuecomment-2259003979 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.
Der Drucker ist aus Papier.
Lol. That sounds like it would be a problem.
If/when this issue is fixed https://github.com/php/php-src/commit/6d5962074f60b401ab5797333c00d292f36f3d90 should be reverted.
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.
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:
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_EXCEPTION
s (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.setjmp()
calls __intrinsic_setjmp
(what might explain that there are no issues with vs16; I haven't checked what vs16 compiles, though)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.
Note that adding --repeat 2 and improving the JIT flags as per https://github.com/php/php-src/pull/12406 also creates a number of additional issues: https://github.com/danog/php-src/actions/runs/11869776299/job/33080469494#step:6:470
Description
As of https://github.com/php/php-src/commit/4dc77953ebd7e4ad47fa3da83ab32cd069b00256, a couple of tests are crashing. (Note that the issues have no introduced by this commit, but are merely visible now.)
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