Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API request: Free heap blocks available (same as memmgr_heap_printf_free_blocks) #3534

Open
noproto opened this issue Mar 21, 2024 · 3 comments
Assignees
Labels
Core+Services HAL, furi & core system services Feature Request New feature or user-story you wanna add to flipper

Comments

@noproto
Copy link
Contributor

noproto commented Mar 21, 2024

Description of the feature you're suggesting.

Currently there's no way to check all of the available heap blocks of memory via the API.

It's not possible to plan heap allocation without repeatedly reserving memory and checking the next largest block with memmgr_heap_get_max_free_block (and if there's insufficient memory rolling back all of the allocations and re-allocating).

The only way I can see (which is a hack) is by setting up a log handler with furi_log_add_handler, call memmgr_heap_printf_free_blocks to dump the free blocks to the log buffered output stream, read back the log and parse each line, then use that in any heap memory planning function.

It would be very helpful to expose a function which can be used to plan help allocation/memory management in FAPs. If the largest sized block isn't checked, any malloc can fail freezing the device.

Anything else?

No response

@CookiePLMonster
Copy link
Contributor

Would this idea accomplish much? There are many services running on the device at any point and FreeRTOS employs dynamic allocation, so if you used the result of such a function to plan your allocations, you could run into a race where the block(s) were free when you checked, but they stopped being free when you are allocating.

Sounds like it'd be better to guarantee that a failed malloc is "safe" and returns null instead of freezing/crashing.

@noproto
Copy link
Contributor Author

noproto commented Mar 21, 2024

Both ideas aren't mutually exclusive. This is a low LoE change that will, regardless of possible race conditions, significantly reduce the number of crashes that users experience running my application. In my tests I haven't observed any background services consuming significant RAM unexpectedly.

@hedger hedger added Feature Request New feature or user-story you wanna add to flipper Core+Services HAL, furi & core system services labels Mar 21, 2024
@DrZlo13
Copy link
Member

DrZlo13 commented Apr 8, 2024

@noproto I'm currently integrating new tlsf memory allocator #3572, which is much more mature and ram-friendly than our heap4 allocator. During the integration process, I created a block walker method to eliminate potential heap corruption (enumerating the heap without locking the kernel is bad, mmmkay?), and it solves exactly your problem, allows you to enumerate memory blocks.

@DrZlo13 DrZlo13 self-assigned this Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core+Services HAL, furi & core system services Feature Request New feature or user-story you wanna add to flipper
Projects
None yet
Development

No branches or pull requests

4 participants