mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-09 10:52:37 +00:00
987658dcee
These five tests (mbox_api, mheap_api_concept, msgq_api, pipe_api and queue) all had test cases where they needed a mem_pool allocation to FAIL. And they are all written to assume the behavior of the original allocator and not the more general k_heap code, which actually succeeds in a bunch of these cases. * Even a very small heap saves enough metadata memory for the very small minimum block size, and this can be re-used as an allocation. So you can't assume a small heap is full. * Calculating the number of blocks based on "num_blocks * max size / minimum size" and allocating them does not fill the heap, because the conservative metadata reservation leaves some space left over. So these have all been modified to "fill" a heap by iteratively allocating until failure. Also, this fixes a benign overrun bug in mbox. The test code would insert a "big" message by reading past the end of the small message buffer. This didn't fail because it happened to be part of an array of messages and the other ones defined contained the memory read. But still. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| common | ||
| context | ||
| device | ||
| early_sleep | ||
| fatal | ||
| fifo | ||
| fp_sharing | ||
| gen_isr_table | ||
| interrupt | ||
| lifo | ||
| mbox | ||
| mem_heap/mheap_api_concept | ||
| mem_pool | ||
| mem_protect | ||
| mem_slab | ||
| mp | ||
| msgq/msgq_api | ||
| mutex | ||
| obj_tracing | ||
| pending | ||
| pipe | ||
| poll | ||
| profiling/profiling_api | ||
| queue | ||
| sched | ||
| semaphore/semaphore | ||
| sleep | ||
| smp | ||
| spinlock | ||
| stack/stack | ||
| threads | ||
| tickless | ||
| timer | ||
| workq | ||
| xip | ||