zephyr: alloc: virtual_heap_free: Panic on deallocations errors #9779
Conversation
Add k_panic() function call in error handling code to help detect potential memory release errors. The vmh_free function returns an error if: 1. heap belongs to another core, 2. given pointer to be freed is invalid (doesn't belong to the allocator), 3. there is an error in the code determining the size of the block to be freed 4. memory unmapping fails. Log entry is easy to miss, stopping the firmware at this point will draw attention to a critical problem related to memory allocation. Otherwise, it will have a slowly progressing memory leak. Signed-off-by: Adrian Warecki <[email protected]>
softwarecki
requested review from
lyakh,
lgirdwood,
ArsenEloglian,
abonislawski,
kv2019i,
marcinszkudlinski,
jxstelter,
piotrkmx,
kfrydryx,
pjdobrowolski,
tmleman,
serhiy-katsyuba-intel and
gbernatxintel
| tr_err(&zephyr_tr, "Unable to free %p! %d", ptr, ret); | ||
| k_panic(); |
There was a problem hiding this comment.
Do we really want to panic ? e.g. would a user space module be able to panic with a bad free() ? (and stop all other pipelines)
There was a problem hiding this comment.
Do we really want to panic ? e.g. would a user space module be able to panic with a bad free() ? (and stop all other pipelines)
+1 - maybe we should add some notification to the host about similar important but not fatal errors
There was a problem hiding this comment.
failure of memory release:
- In the best situation it will lead to memory leak (and crash, sooner or later)
- in the worst - undefined actions because of cache inconsistency
In any case - we DO have a bug and it is a serious problem, and it is very hard to notice only by a line in the log.
For me panic is fine here. OR - we may consider an assert that is checked in debug only.
Anyway, SOF has no kernel that keeps the system working when an application crashes, "user space module" is in fact a part of the system, not an application.
Add k_panic() function call in error handling code to help detect potential memory release errors.
The vmh_free function returns an error if:
Log entry is easy to miss, stopping the firmware at this point will draw attention to a critical problem related to memory allocation. Otherwise, it will have a slowly progressing memory leak.
If we decide this is a desirable change, we can merge it after #9776 and #9777 have been merged.