Segfault with Relay\Cluster 0.11.0 (while trying to make it work with symfony/cache)

[dorrogeray]

Hi,

I am working to make symfony/cache compatible with Relay\Cluster using relay 0.11.0, and I have run into what looks like mis-mapped or mis-typed the PHP method signature (at least according to how GPT4 parses the backtrace)

I have captured the backtrace in this branch: https://github.com/dorrogeray/symfony/tree/cache-support-relay-cluster-0-11-0 and the issue should be reproducible just by running php test.php in the root of the repository (with valid seeds).

I have reproduced it on:

OS: Amazon Linux release 2023.6.20250317 (Amazon Linux)
PHP:

PHP 8.2.28 (cli) (built: May 19 2025 12:02:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.28, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.28, Copyright (c), by Zend Technologies
    with Xdebug v3.4.3, Copyright (c) 2002-2025, by Derick Rethans

Here is summary from GPT4:

The backtrace makes it quite clear this is not a core-PHP bug but rather a crash inside custom “relay” extension, specifically in the C function relayClusterProcessCommand. Here’s what we can pull out:

1. Faulting location

   #0  relayClusterProcessCommand (…) at /root/relay/src/commands.c:13767
   

   The crash happens on line 13767 of your extension’s commands.c. That function is being passed a tiny integer (dst=0x4f) instead of a valid pointer, so it immediately dereferences garbage and SIGSEGVs.

2. Call chain

   relayClusterProcessCommand
   relayClusterCommand       ← your extension’s wrapper for PHP
   ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER
   execute_ex
   zend_execute
   zend_execute_scripts
   php_execute_script
   do_cli
   main
   

   After the invalid C call, the PHP engine simply unwinds. There are no other PHP extension frames before the crash, so it’s definitely your code (and not, say, the VM or another extension).

3. Bad argument (dst=0x4f)
   In relayClusterProcessCommand(dst=0x4f, rqs0=0x0, …) the first parameter should be a pointer to some internal cluster‐object, but instead it’s the integer 79 (0x4f). That almost always means you mis-mapped or mis-typed the PHP method signature, so when Zend invokes your native function it’s passing the wrong zval slots.

4. Next steps

   • Open commands.c around line 13767 and see what dereference is happening there (likely something like dst->…).
   • Check your ZEND_METHOD / zend_function_entry table: are you declaring the proto properly? For instance, if your C function takes (ClusterObject *co, zend_string *key, …), you need to match that in ZEND_ARG_OBJ_INFO / ZEND_ME or whatever wrapper.
   • Rebuild the extension with -g -O0 and step through under gdb to see exactly which pointer is bad.
   • Add sanity checks at the top of relayClusterProcessCommand to validate that dst is non-NULL and of the correct class entry.

Because all the PHP frames above are literally just the VM dispatching a CLI file called test.php you wrote, there’s nothing in your script causing it other than calling into this extension. Once you fix the signature/memory management in your Relay C code, the segfault should go away.

[michael-grunder]

Thanks, this is a great issue report.

The bug is happening in Cluster->zUnionStore and I aggree 0x4f is almost certainly due to doing something like obj->member when obj == NULL, because offsetof(obj, member) = 0x4f.

It could also be something much more horrible but hopefully not 🤞

I don't know how many moving parts are invovled, but is it possible to get some kind of reproducer? It could be as simple as serializing an array of the exact arguments being sent to zUnionStore that causes the segfault. This could be harder if also needs Relay to be in a specific state.

I will throw my fuzzer at Relay\Cluster->zUnionStore and also just take a look to see if we're missing a null check somewhere obvious.

Thanks!

[dorrogeray]

Hi,

the reproducer is in the branch: https://github.com/dorrogeray/symfony/blob/cache-support-relay-cluster-0-11-0/test.php

it happens when the $initializer callback returns. This happens once $redis->get('x') is called and the proxy needs to create the actual Relay\Cluster instance. Note that the class RelayClusterProxy extends Cluster, maybe there is some type mismatch on the interface between the Proxy and how Relay\Cluster is typed internally? https://github.com/dorrogeray/symfony/blob/cache-support-relay-cluster-0-11-0/src/Symfony/Component/Cache/Traits/RelayClusterProxy.php#L27

[michael-grunder]

Thanks!

It turns out I was actually looking at the wrong source file 😂. @yatsukhnenko Found the right line and the fix is almost certainly trivial. I'll try to get one up this weekend and then we can do a small patch release next week.

[dorrogeray]

Thats great news, thanks! 🙂

[tillkruss]

This was fixed in nightly builds.