I cannot reproduce the segfault (PHP-8.1 on Windows CLI; tried with JIT and without). If I put var_dump($modifiers); in the loop body, I get the expected:

enum(App\Domain\TournamentTable\ResultsModifier::AWAY)
enum(App\Domain\TournamentTable\ResultsModifier::HOME)
enum(App\Domain\TournamentTable\ResultsModifier::OVERTIME)
enum(App\Domain\TournamentTable\ResultsModifier::REGULATION_TIME)

Can you please provide a stack backtrace?

I would be happy to, and I have the coredump file, but when I compiled php with the --enable-debug flag, my application no longer runs:

Assertion failed: zval_get_type(&(*(z))) < 6 (/usr/src/php/ext/opcache/zend_persist_calc.c: zend_persist_zval_calc: 138)

So I can't, sorry.

I think you still could get a backtrace if you're running under gdb; after the assertion has been triggered, typing bt should provide it. However, I guess the assertion failed due to a prior memory corruption. Are you running with JIT enabled (if in doubt, check PHP info)? If so, what's the value of opcache.jit?

I failed at it. As far as I understand, gdb attaches to one of the fpm processes. But my php-fpm (when compiled with --enable-debug) doesn't start at all. I should also clarify that I observe this in a docker container inside a kubernetes pod.

Also, I cannot reproduce it running same script in CLI (even with opcache.enable_cli => On).

In answer to the second question:

php -i | grep "jit"
auto_globals_jit => On => On
pcre.jit => 1 => 1
opcache.jit => tracing => tracing
opcache.jit_bisect_limit => 0 => 0
opcache.jit_blacklist_root_trace => 16 => 16
opcache.jit_blacklist_side_trace => 8 => 8
opcache.jit_buffer_size => 0 => 0
opcache.jit_debug => 0 => 0
opcache.jit_hot_func => 127 => 127
opcache.jit_hot_loop => 64 => 64
opcache.jit_hot_return => 8 => 8
opcache.jit_hot_side_exit => 8 => 8
opcache.jit_max_exit_counters => 8192 => 8192
opcache.jit_max_loop_unrolls => 8 => 8
opcache.jit_max_polymorphic_calls => 2 => 2
opcache.jit_max_recursive_calls => 2 => 2
opcache.jit_max_recursive_returns => 2 => 2
opcache.jit_max_root_traces => 1024 => 1024
opcache.jit_max_side_traces => 128 => 128
opcache.jit_prof_threshold => 0.005 => 0.005

opcache.jit_buffer_size => 0 => 0

So OPcache JIT is disabled. I have no idea how to proceed here; maybe someone else has.

I also tried reproducing this, to no avail.

I would be happy to, and I have the coredump file, but when I compiled php with the --enable-debug flag, my application no longer runs

The assertion hints at z holding an unexpected value. You could place a breakpoint at that line and check what z->u1.v.type returns. According to that assert it should be < IS_STRING (6), so a primitive zval with no additional data.

We are meeting very similar issue. Disabling opcache helps.

Seems like even disabling preloading helps in our case.

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.

Thanks for the hint, I can reproduce it with preloading.

Thanks!

Just for the record, we're experiencing really strange errors after re-enabling preloading on PHP 8.1.6, as if the memory was somehow messed up:

return BillingType::tryFrom($value);

where BillingType is regular backed enum:

enum BillingType: string
{
    case Terms = 'terms';
    case Prepaid = 'prepaid';
}

fails on following error:
Fulfillment\CommonBundle\Utils\EnumHelper::create(): Return value must be of type BackedEnum, Doctrine\ORM\Id\IdentityGenerator returned, which does not make any sense.

We're still using the same preloading configuration which worked before transitioning from constants to enums and the code works just fine with preloading disabled.

I'll try to create a reproducible case and submit a new issue, I just wanted to warn others about possible problems for now.

@olsavmic, yes, please file a new ticket. :)

@olsavmic You never created an issue for this, are you still experiencing this problem?

@iluuu1994 Yes, the issue still occurs, we're running with preloading disabled. I was just not able to create a reproducible test case nor extract some insightful logs as I was quite busy for the past week (and will be for the week to come).

If you're fine with creating an open issue with no more details than those I posted to this channel, I'll create the issue offhand :)

@olsavmic It can also wait until you have more information, I just wanted to confirm this is still an issue. 🙂 Thanks for your response.