@aaron and I reviewed the memcached PECL code, but we did not find anything which would cause this.

From the logs, there seems to have been a single instance of failure, causing a burst of 3102 events from a single server (wtp1046). I don't think this is high priority unless it happens more often.

Behaviour will be an exception with php8 - https://github.com/php-memcached-dev/php-memcached/commit/9a429d43f8a4aab9292287502a3393588e2255c1

An exception would actually be preferable. This is not a problem for PHP 8 support.

I wondered whether it's possible for an Excimer callback to execute after object creation but before the constructor is called. I used the following code:

$timer = new ExcimerTimer; 
$timer->setInterval( 1 ); 
$timer->setCallback(
    function() {
        throw new \Exception('ping');
    }
);
$timer->start();
$memcached = new Memcached;
$memcached = null;

Then I put gdb breakpoints on php_memc_object_new, zim_Memcached___construct and excimer_timer_interrupt. Gdb stopped in php_memc_object_new and I waited for the 1 second timer to expire. The constructor was then successfully called before the interrupt function. The first opportunity for the interrupt function is at the end of the DO_FCALL handler which calls __construct().

Similarly, with a breakpoint in php_memc_object_free_storage, I was able to confirm that there is no opportunity for the interrupt function to run between php_memc_object_free_storage and final destruction of the enclosing zval.

I did these tests on a recent version of PHP git master (8.1-dev, 3a867b982755501b514d19418086972a0cc693e7) and the current memcached PECL git master.

It could be that our code regressed and we're actually no longer calling the constructor when we should, but I'm gonna say that's very unlikely or the warning would be more common.

I think the only way that could happen is by subclassing the Memcached class, but we're not doing that.

It could be that the WMFTimeoutException might be happening in a destructor call during gargage collection and maybe the state was there but already lost?

The convention is that no userspace code runs between the free_obj handler and the destruction of all references. The garbage collector respects this by queuing objects to be deleted, incrementing their reference counts and calling all their __destruct() functions. Then in a second pass, it calls their free_obj handlers. The free_obj handler is not meant to run userspace code, and probably doesn't.

It could be that somehow WMFTimeoutException disrupted an assumed-atomic section in memcached-pecl and then later on during another getMulti call it assumed the setup was done when it wasn't actually?

That's basically the theory I'm testing, but I haven't been able to reproduce it. When you do $memcached = new Memcached, that is implemented as three opcodes:

1. new
2. Memcached::__construct()
3. assignment

If the object is used between 1 and 2, this warning will be seen, but my test with gdb shows the interrupt flag is not being checked at that time. And even if an exception is thrown between 1 and 2, how would subsequent code get the object and call methods on it when the assignment (3) hasn't been done?

Destruction seems even less likely as a cause. It goes something like:

1. refcount decremented to 0
2. refcount incremented to 1
3. __destruct() called
4. free_obj called
5. refcount decremented to 0
6. storage freed

Here the atomic section is between stage 4 and 5, but it's hard to imagine the interrupt flag being checked at that time, because it doesn't re-enter the VM.