Hi Rob On Mon, Mar 10, 2025 at 9:23 AM Rob Landers <rob@bottled.codes> wrote: > > I’ve been trying to chase down a very subtle bug in 8.4 that only happens > when OPcache is enabled (I'm trying to create a reproducer to file an actual > bug). From what I can tell, OPcache doesn’t zero out cache slots, so > occasionally, a cache slot will contain garbage that happens to pass > asserts/checks that causes the program to behave incorrectly. Without > OPcache, cache slots are always NULL if not set. > > It's quite rare to end up in that situation, though, but I was wondering if > anyone has any opinions on this?
I don't believe this is accurate. If we're talking about the cache used within the VM, "cache slots" are a contiguous list of arbitrary void pointers. The compiler tracks how many cache slots each function needs, but the actual array of pointers is allocated at runtime, in init_func_run_time_cache_i(), when the function is executed for the first time on each request. init_func_run_time_cache_i() zeros the cache with memset. If it wouldn't, we'd run into issues quickly, because a non-0 cache is generally interpreted as a primed cache. Potentially, you might also be referring to the pointer map, which is a related concept. But this map is also zero'ed for each request (in zend_activate()). If you think you might be dealing with uninitialized memory in your case, MemorySanitizer or Valgrind may help. Does that help? Ilija
