Assertion `(flag & (1<<3)) == 0' failed.

[Changochen]

Description

The following code:

<?php
class A
{
    function __set($o, $l)
    {
        $this->$p = $v;
    }
}
$a = new A();
$pp = "";
$op = $pp & "";
$a->$op = 0;
?>

Resulted in this output:

/Zend/zend_hash.c:763: zval *_zend_hash_add_or_update_i(HashTable *, zend_string *, zval *, uint32_t): Assertion `(flag & (1<<3)) == 0' failed.

Build config:

./configure --disable-all --enable-address-sanitizer --disable-phpdbg --disable-cgi --with-pic --enable-debug-assertions
make -j

PHP Version

PHP 8.3.0-dev

Operating System

No response

[nielsdos]

I confirm this happens on 8.1 and higher.

Analysis:

Upon attempting to store the empty string in the magic set method we first reach this code

php-src/Zend/zend_object_handlers.c

Lines 549 to 551 in 047c978

	/* mark pointer as "special" using low bit */
	zend_hash_add_new_ptr(guards, str,
	(void*)(((zend_uintptr_t)&Z_PROPERTY_GUARD_P(zv)) | 1));

but the strings str and member are actually equal content-wise (their pointers are different, but the characters are the same: both the empty string). This shouldn't happen because of the string equality check above. Later we execute the following:

php-src/Zend/zend_object_handlers.c

Line 571 in 047c978

return (uint32_t*)zend_hash_add_new_ptr(guards, member, ptr);

And now a new entry isn't actually added because the first snippet I linked added it. Therefore the assertion fails.

Cause:

The following check should've prevented this:

php-src/Zend/zend_object_handlers.c

Lines 537 to 540 in 047c978

	if (EXPECTED(str == member) ||
	/* "str" always has a pre-calculated hash value here */
	(EXPECTED(ZSTR_H(str) == zend_string_hash_val(member)) &&
	EXPECTED(zend_string_equal_content(str, member)))) {

But it turns out that the hash of str is zero here! I did a quick test by changing ZSTR_H(str) to zend_string_hash_val(str) and now the OP's code no longer crashes, indicating that the hash being zero is indeed the problem.

[Girgias]

I would expect that any empty string to be "optimized" to the interned zend_empty_string zend_string which has the hash precomputed. So it seems the is an issue with the bitwise & operator (which might be generalized to other operators)

[nielsdos]

Yeah it also breaks with bitwise |.

[nikic]

The line comparing hashes should just be dropped. member is not guaranteed to have a hash, and member is assigned to str, so it doesn't necessarily have a hash either. (Or else we'd have to force a hash calculation when assigning str.)

[nielsdos]

I see, I'll make a PR for that change this afternoon.