BackedEnum::from()/tryFrom()/cases() return values having no relation to this enum

[cracksalad]

Description

The following code:

<?php
declare(strict_types=1);

namespace entity\type;

enum Priority: string {
 case LOW = 'low';
 case MEDIUM = 'medium';
 case HIGH = 'high';
}

<?php
declare(strict_types=1);

namespace recommendation;

use entity\type\Priority;
// [...]

class Handler {
 // [...]
 protected function parsePriority(MyClass $target, array $results): void {
 if(isset($results['priority']['value'])){
 $priority = Priority::tryFrom($results['priority']['value']);

 App::getLogger()->debug('got priority value', [ // Monolog logger
 'value' => $priority,
 'original' => $results['priority']['value'],
 'cases' => OptimizedActionPriority::cases()
 ]);

 if($priority !== null){
 $target->setPriority($priority); // line 206
 }
 }
 }
// [...]

<?php
declare(strict_types=1);

namespace entity;

use entity\type\Priority;

class MyClass {
 // [...]
 public function setPriority(Priority $priority): void { // line 59
 // [...]
 }
 // [...]
}

Resulted in roughly 80 % of cases in the expected output, but in 20 % of cases in this output:

• Log output (note that opis/json-schema is a dependency of my project`):

got priority value {"value":{"Opis\\JsonSchema\\Parsers\\Keywords\\MinimumKeywordParser":[]},"original":"medium","cases":[{"entity\\type\\OptimizedActionPriority":"low"},{"Opis\\JsonSchema\\Parsers\\Keywords\\MinimumKeywordParser":[]},{"entity\\type\\OptimizedActionPriority":"high"}]}

• Output:

[object] (TypeError(code: 0): entity\\MyClass::setPriority(): Argument #1 ($priority) must be of type entity\\type\\Priority, Opis\\JsonSchema\\Parsers\\Keywords\\MinimumKeywordParser given, called in src/recommendation/Handler.php on line 206 at src/entity/MyClass.php:59)
 [stacktrace]
 #0 src/recommendation/Handler.php(206): entity\\OptimizedAction->setPriority()
 #1 src/recommendation/[...]: recommendation\\OptimizedActionHandler->parsePriority()
 // [...]
 #6 [internal function]: {closure:scripts/worker/gearman-worker.php:131}()
 #7 scripts/worker/gearman-worker.php(221): GearmanWorker->work()
 #8 {main}

But I expected this output instead:

• Log output:

got priority value {"value":{"entity\\type\\OptimizedActionPriority":"low"},"original":"low","cases":[{"entity\\type\\OptimizedActionPriority":"low"},{"entity\\type\\OptimizedActionPriority":"medium"},{"entity\\type\\OptimizedActionPriority":"high"}]}

Notes:

• Sadly, I was not (yet) able to reproduce this in a minimal example and I did not find any reference online describing a similar behavior. I am a little desperate right now
• All the PHP code runs in a CLI context rather than FastCGI and is called via a Gearman worker (although the observed behavior should not happen, regardless of the context, I guess)
• The observed $priority values are either correct or randomly chosen class instances, that were used by the same script during the same execution. So, it might be a memory access issue?!
• The real example above is especially weird, since the "low" value from cases() is actually correct, while the tryFrom("low") value is not. You see the randomness here?
• Same behavior is to observe replacing tryFrom() with from() (and no ValueError is thrown)
• I tried renaming the enum (I assumed a name collision of some sort), although I can not rename the values since they need to match the API responses

PHP Version

Tested with

PHP 8.4.19 (cli) (built: Mar 10 2026 15:51:04) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Remi's RPM repository <https://rpms.remirepo.net/> #StandWithUkraine
Zend Engine v4.4.19, Copyright (c) Zend Technologies
 with Zend OPcache v8.4.19, Copyright (c), by Zend Technologies

as well as

PHP 8.3.30 (cli) (built: Jan 13 2026 22:36:55) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.3.30, Copyright (c) Zend Technologies
 with Zend OPcache v8.3.30, Copyright (c), by Zend Technologies

Operating System

AlmaLinux 9

[iluuu1994]

Hi @cracksalad. Memory corruption is possible. Two questions:

• Are you using the JIT?
• Do you have any 3rd party extensions enabled?

Can you try without both and see if it resolves your issue?

[cracksalad]

Hi @cracksalad. Memory corruption is possible. Two questions:

* Are you using the JIT?

* Do you have any 3rd party extensions enabled?

Can you try without both and see if it resolves your issue?

Thank you for your tips!

• I did not configure JIT until now (which I assume means "tracing" for 8.3 and "disable" for 8.4). It is disabled now.
• I use a few third party extensions. Most of them I would describe as passive like imagick, memcached, igbinary, lz4, msgpack, gnupg and gearman. In this context only memcached and gearman are really used. I will try to disable as many as possible without breaking anything.

Need to wait and observe for a bit, before I can tell if the behavior has changed.

[iluuu1994]

Thanks! It's worth noting that even applications you consider passive can have an effect down the line. Frequently, the effects of memory corruption aren't immediately evident.

[cracksalad]

In the meantime...

• I still observed the issue when JIT was explicitly disabled.
• I did not observe the issue for 24h, when msgpack, igbinary, imagick and lz4 were disabled (not noticing that memcached depends on msgpack and igbinary and was thereby somewhat disabled as well)
• I did observe the issue again in a matter of 30 minutes, once I reenabled igbinary and msgpack.

So, next step would be to build memcached myself (currently installed via OS package manager) to differentiate it from msgpack and igbinary.
Luckily it does not seem to be a "PHP itself" issue by now.
What exactly do I have to look for once the problematic extension is identified? Do you assume the general C memory access issues?
I guess, technically speaking the issue can still be caused by some unwanted interaction between several extensions, couldn't it? Let's just not hope for that.

[iluuu1994]

Thanks for your analysis.

If you have the ability to compile the extension yourself, you can try enabling the ./configure --enable-address-sanitizer flag, which can catch many memory violations. Alternatively, you can try running your application with Valgrind. Neither of them should be done in production, and both of them will require setting the USE_ZEND_ALLOC=0 env variable to catch the most errors.