task_mem_map_used_get() keep decreasing even when free unallocated blocks

[zephyrbot]

Reported by Sharron LIU:

In extensive test against task_mem_map_used_get(), below four cases were checked, failed in case #4.

case #1: verify mmap used get after allocation succeed
case #2: verify mmap used get after allocation failed (e.g. no free blocks)
case #3: verify mmap used get after free allocated blocks
case #4: verify mmap used get after free un-allocated blocks (e.g. freed blocks are free again)

how-to-reproduce (attached test case)

# source zephyr-env.sh
# make -C test_mmap_api_used_get pristine
# make -C test_mmap_api_used_get flash

verify test case failed at main@103 "mmap: used get failed after free unallocated blocks".

user impact
Zephyr application run in multi-thread contexts, and memory alloc/free can be done from different threads. And it likely happen that app try to request memory when no free blocks are available, or a memory block is freed twice or more. "task_mem_map_used_get()" should report correct status in the above two cases, and grantee successive alloc/free are handled with correct "amount of used blocks". Or at least make it convenient for debugging, raise an assertion when app try to free an un-allocated block.

(Imported from Jira ZEP-418)

[zephyrbot]

by Sharron LIU:

• test_mmap_api_used_get.tgz (size: 1652)

[zephyrbot]

by Benjamin Walsh:

Working as intended. Test is invalid.

It is up to the application to make sure it does not do a double-free, even if the application is multi-threaded.

An assertion cannot be done either with the current implementation because the whole memory block is allocated as opaque data and does not contain any meta-data that tracks if it is allocated or not. This is done to maximize memory usage. When queued in the memory-map, the first few words are used to queue the block, but that is undistinguishable from data, and the same exact contents could be valid data if the block were an allocated block.

[zephyrbot]

by Sharron LIU:

Thanks for clarification. Will remove case #4 check point.

[zephyrbot]

by Mark Linkmeyer:

Fixing incorrect priority