We should compare the block memory, not the block metadata (See
zend_mm_add_huge_block).
This caused random test failure for ext/ffi/tests/gh14626.phpt when the
malloc() performed by the FFI code lies close to the block metadata, and
the size of the block is large enough.
This was reported by https://github.com/php/php-src/issues/16902#issuecomment-2498310452
Closes GH-16938.
is_zend_ptr() expected zend_mm_heap.huge_list to be circular, but it's in fact NULL-terminated. It could crash when at least one huge block exists and the ptr did not belong to any block.
Right-shifting a negative number is unspecified (i.e.
implementation-defined) behaviour [1]. If we take a look at the
generated assembly [2], we see that the wrong value is computed.
Fix it by using Z_UL instead of Z_L.
While we're at it, just change every occurrence of this pattern to use
Z_UL instead of casting.
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf §6.5.7.5
[2] https://godbolt.org/z/4Y1qKKjsh
Closes GH-12613.
This does still deviate from USE_ZEND_ALLOC=0 in that we're not rounding up the
size of the allocation to fixed sizes. Doing so would suppress some
out-of-bounds errors checked by ASAN. Rounding up the size in
_zend_mm_block_size would not be good either as it would break code like
memset(ptr, 0 _zend_mm_block_size(ptr)).
Shift header include
In the C file, include the header first so missing #includes are
detected by the compiler, and use lighter header dependencies in the
header, to speed up compile times.
The new Linux 5.17 feature PR_SET_VMA_ANON_NAME can give names to
anonymous private memory, see:
https://lwn.net/Articles/867818/
It can be useful while debugging, to identify which portion of the
process's memory belongs to which subsystem.
This is how /proc/PID/maps can look like:
555ccd400000-555ccdc00000 r-xp 00000000 00:00 0 [anon:huge_code_pages]
7f6ec6600000-7f6ec6800000 rw-p 00000000 00:00 0 [anon:zend_alloc]
The first mapping is the PHP executable copied to anonymous memory by
option "opcache.huge_code_pages". The second one is a memory area for
the "zend_alloc.h" memory allocator library.
Unfortunately, it is not possible to give names to shared memory
(MAP_SHARED), because Linux MAP_SHARED really maps /dev/zero (see
shmem_zero_setup()), which makes madvise_vma_anon_name() believe this
is a file mapping, failing the prctl() with EBADF.
* Zend/zend_alloc: make zend_mm_use_huge_pages static
This is an internal variable and it should not be exported.
* Zend/zend_alloc: convert zend_mm_use_huge_pages to bool
* Zend/zend_alloc: convert has_free_pages to bool
* Zend/zend_alloc: convert empty to bool
The amount of allocated system memory is kept in `real_size`, including
the allocated `cached_chunks`. Thus, we need to keep the proper count
at the end of the shutdown.
Closes GH-7745.
oss-fuzz currently coalesces all leaks into one issue, presumably
because the five lowest stack frames always look the same. Let's
see whether dropping the __zend_malloc() frame helps.
Move this code directly into the error handler, and check the
heap->overflow flag. Discarding output here allows us to print
the normal memory limit message to standard output. Otherwise
nothing would be printed unless a different log medium was used,
which makes for a suboptimal debugging experience.
As PHP has a minimum memory usage of 2M (size of allocator chunk),
setting a limit below that value is not meaningful and will be
automatically rounded up to the chunk size. Rather than doing this
silently, show the newly introduced error message.
The memory limit had to be increased to 2M for a number of tests.
tests/lang/bug45392 has been marked as XFAIL. This old bugfix is
not working as intended. The memory limit in main's `PG(memory_limit)`
differs from the one in zend_alloc. In zend_alloc the `AG(mm_heap)->limit`
is defined as `max(passed_value, ZEND_MM_CHUNK_SIZE)`. The check made in
an unclean shutdown will never be true unless the memory limit is lower
than ZEND_MM_CHUNK_SIZE, which happened to be the case in the test.
https://bugs.php.net/bug.php?id=45392fcc0fdd125
When the memory limit is reduced using an `ini_set("memory_limit", ..)`
below the currently allocated memory, the out-of-memory check overflowed.
Instead of implementing additional checks during allocation,
`zend_set_memory_limit()` now validates the new memory limit. When
below the current memory usage the ini_set call will fail and throw
a warning.
This is part of GH-7040.
This PR corrects misspellings identified by the check-spelling action.
The misspellings have been reported at jsoref@b6ba3e2#commitcomment-48946465
The action reports that the changes in this PR would make it happy: jsoref@602417c
Closes GH-6822.
