[WIP] Attempt to fix opcache_reset() races

[nielsdos]

This is related to both #8739 and #14471. In particular to the latter.

I observe that there are data races possible against &ZCSG(hash) between zend_accel_hash_find_entry and zend_accel_add_key. We use the bucket return value from zend_accel_hash_find_entry and use it as a data pointer for zend_accel_add_key. However, if the &ZCSG(hash) table is modified in between those calls, then we end up with inconsistent data in the hash table. This is possible for example with opcache_reset().

We can observe this is the case by adding memset(accel_hash->hash_entries, 0xf0, sizeof(zend_accel_hash_entry )*accel_hash->max_num_entries); at the bottom of zend_accel_hash_clean which causes a dereference at address 0xf0f0f0f0f0f0f110 when walking the bucket chain in zend_accel_hash_find_entry.

I ran the test from GH-14471 with opcache.interned_strings_buffer=0 and it is much more stable. Prior to this patch it would constantly crash after a while. With the interned strings buffer not zero I still observe crashes. Even with the buffer size 0, not all issues are fixed yet, see #8739 (comment) for example. I would need some feedback or guidance.

One problem I think is still there is when returning a string from the hash table with zend_string *str = zend_string_copy(persistent_script->script.filename);, if that string is in the interned hash table then nothing is preventing a restart from clearing out the filename string.

[dstogov]

Please think about a different solution. This one should make a big slowdown.

opcache should be able to do lock-free cache lookups.
Probably, the modification of ZCSG(hash) should be done more careful (to keep consistency for concurrent readers)