heap_caps_*_prefer functions will now only call heaps_caps_alloc_failed
callback if all attempts to allocation memory fail (and not after each attempt
anymore).
* Closes https://github.com/espressif/esp-idf/issues/9086
heap: ported tlsf allocator into multi heap
heap_host_tests: added tlsf allocator into host test
heap_host_test: update freebytes after using free
heap_tests: tlsf now passing on host tests without poisoning
multi_heap: added support for memalign using tlsf implementation
heap_caps: removed heap_caps_aligned_free
heap/test: fixed broken aligned alloc test build
heap: added poisoning pattern when blocks are being merged
heap/tests: added timing tests for memory allocation
heap: reduced tlsf structure overhead
heap/tlsf: made all short functions inside of tlsf module as inline to improve timings
heap: moved tlsf heap routines outside of flash memory
newlib: linked multiheap memalign with newlib memalign function
heap: moved block member functions to a separate file so multi_heap can use the functions
heap/test: improved the tlsf timing test
heap/test: added memalign on aligned alloc tests
heap: moved tlsf configuration constants to a separated file
heap: added random allocations test with timings
heap: modified the calculation of heap free bytes
heap: make aligned free true deprecated functions and update their documentation
heap: add extra assert after successive mallocs on small allocation host test
heap: remove legacy aligned alloc implementation.
performance: added malloc and free time performance default values
Goal is that multiple faults would be required to bypass a boot-time signature check.
- Also strengthens some address range checks for safe app memory addresses
- Change pre-enable logic to also check the bootloader signature before enabling SBV2 on ESP32
Add some additional checks for invalid sections:
- Sections only partially in DRAM or IRAM are invalid
- If a section is in D/IRAM, allow the possibility only some is in D/IRAM
- Only pass sections that are entirely in the same type of RTC memory region
Add back a feature that was available in the old heap implementation
in release/v2.1 and earlier: keep track of which task allocates each
block from the heap. The task handle is conditionally added as
another word in the heap poisoning header under this configuration
option CONFIG_HEAP_TASK_TRACKING.
To allow custom monitoring and debugging code to be added, add helper
functions in multi_heap.c and multi_heap_poisoning.c to provide access
to information in the block headers.
Add esp_heap_debug_dump_totals() to monitor heap usage
esp_heap_debug_dump_totals() dumps into a user-provided data structure
a summary of the amound of heap memory in region type that is used by
each task. Optionally it will also dump into another data structure
the metadata about each allocated block for a given list of tasks or
for all tasks (limited by available space).
Address change requests on PR #1498
This set of changes fixes the files in e3b702c to just add the
CONFIG_HEAP_TASK_TRACKING option without adding the new function
heap_caps_get_per_task_info() in case that is the only portion of the
PR that will be accepted. Part of the change is to remove the new .c
and .h files containing that function and to remove the line to
compile it from components/heap/component.mk since it should not have
been included in e3b702c. One or more additional commits to add the
new function will follow.
The other changes here:
- uint32_t get_all_caps() moves to heap_private.h
- replace "void* foo" with "void *foo"
- add braces around single-line "if" blocks
- replace tab characters with spaces
Address change requests on PR #1498, part 2
This set of changes fixes the files in cdf32aa to add the new function
heap_caps_get_per_task_info() with its new name and to add the line to
compile it in components/heap/component.mk. This does not address all
the suggested changes because there are some needing further
discussion.
This commit does not include the suggested change to move the
declaration of the new function into esp_heap_caps.h because the new
function references TaskHandle_t so esp_heap_caps.h would have to
include freertos/FreeRTOS.h and freertos/task.h, but FreeRTOS.h
includes esp_heap_caps.h through two other header files which results
in compilation errors because not all of FreeRTOS.h has been read yet.
Change heap_caps_get_per_task_info() to take struct of params
In addition to moving the large number of function parameters into a
struct as the single parameter, the following changes were made:
- Clear out the totals for any prepopulated tasks so the app code
doesn't have to do it.
- Rather than partitioning the per-task totals into a predetermined
set of heap capabilities, take a list of <caps,mask> pairs to
compare the caps to the heap capabilities as masked. This lets the
caller configure the desired partitioning, or none.
- Allow the totals array pointer or the blocks array pointer to be
NULL to indicate not to collect that part of the information.
- In addition to returning the total space allocated by each task,
return the number of blocks allocated by each task.
- Don't need to return the heap capabilities as part of the details
for each block since the heap region (and therefore its
capabilities) can be determined from the block address.
- Renamed heap_task_info.h to esp_heap_task_info.h to fit the naming
convention, and renamed the structs for totals and block details to
better fit the revised function name.
- Provide full Doxygen commenting for the function and parameter
structs.
Add copyright header to new files
Merges https://github.com/espressif/esp-idf/pull/1498
When realloc-ing to a smaller buffer size which ends up allocated in a different heap, the heap
structure is corrupted. This can only happen:
* If heap checking is Comprehensive (meaning buffers are never shrunk in place) and the heap the buffer was originally allocated in is full.
* Calling heap_caps_realloc() to deliberately move a buffer to a different capabilities type, and shrink it at the same time.
Probable fix for https://github.com/espressif/esp-idf/issues/1582
Probably the same issue:
https://www.esp32.com/viewtopic.php?f=2&t=4583https://www.esp32.com/viewtopic.php?f=13&t=3717
