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.
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
Voidification of Zend API which always succeeded
Use bool argument types instead of int for boolean arguments
Use bool return type for functions which return true/false (1/0)
Use zend_result return type for functions which return SUCCESS/FAILURE as they don't follow normal boolean semantics
Closes GH-6002
A very basic limit (for single allocations) was already enforced.
This extends it to count the total memory allocations.
This is useful to avoid out of memory conditions while fuzzing.
Check whether the requested allocation size exceeds limit (rather
than the cumulative size).
This is useful to prevent allocations triggering OOM during fuzzing.
