> On May 21, 2021, at 4:48 PM, Levi Morrison <levi.morri...@datadoghq.com> > wrote: > > Just to check: are you setting the environment variable USE_ZEND_ALLOC > to 0? This causes the engine to use malloc: > https://heap.space/xref/PHP-7.4/Zend/zend_alloc.c?r=600402d9#2738. > > For what it's worth, I was recently annoyed _again_ by valgrind being > so noisy because zend_string_equal_val intentionally reads past the > end of a zend_string. The allocator ensures that memory was allocated, > but it isn't guaranteed to be initialized. We should find some way to > initialize this memory for future releases -- maybe add a function > which null terminates a zend string by adding not 1 null byte but as > many as necessary to reach the end of the allocation. This should be > trivial enough in cost to do, compared to some other solutions like > always zero'ing out the whole memory block or initializing the > trailing bytes at zend_string_alloc time. > > Also, I'm not sure this read-past-the-end technique is actually safe, > such as when USE_ZEND_ALLOC is set to zero and we use malloc directly, > which does not make the same guarantees about alignment and padding on > the string... > > Nikita pushed up this change only today, but it would theoretically > help with valgrind being used a runtime but not compiled with valgrind > support: > https://github.com/php/php-src/commit/a0c44fbaf19841164c7984a6c21b364d391f3750. > I say theoretically only because I haven't tested it yet.
WRT Valgrind: Yes, I do run it with that environment variable, because run-tests sets it for you when using Valgrind. Unfortunately there’s some more false positives, but it’s coming from the library the extension is wrapping. I’d need to take some time to figure out if that’s a false positive, a leak caused by me, or worse, a leak in the library itself. The additional improvements to Valgrind support are welcome though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
