[SOLVED] Monitoring heap usage

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Monitoring heap usage

    I would like to determine the current heap usage (in order to check for memory leaks).

    On platforms that use newlib I can do this by calling mallinfo() but of course SES uses its own C libraries so that is not available to me: what is the equivalent function in the SES world?

    Rob

  • Hello,

    Thank you for your inquiry.
    mallinfo() is no C std lib function which is why it is not available with our current run time libs.
    We will however consider it and put it on our wish list.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Thanks: it is quite an important function to have. Not having it is like driving a car without a fuel gauge; a little worrying when one is, for instance, running on an NRF52 with a "tank" only 64 kbytes in size. And of course, as a matter of principle, one's unit tests should always check that the code they are testing has not leaked any memory, which is impossible without this function.

    Without this function I have to run all the same code on GCC also, which starts to make SES a bit irrelevant: not something you would like to encourage I'm sure!

  • Hello,

    While that might be true >99% of our customers expect fast and/or small code. That is what the SEGGER RTL is optimized for. So our malloc and other memory management functions are as small as possible.
    mallinfo is usually used for Linux systems where resources are no issue. That is usually not the case on embedded targets, especially on Cortex-M targets.
    A generic memory handling where mallinfo is fully implemented would bloat the debug code on your target immensely which is what most of our customers are not looking for.

    For testing and debugging we recommend to wrap or replace the SEGGER RTL memory functions to fit your exact needs.

    Generally we recommend to write your own memory management that is tailored to your exact needs and setup. As there is a near infinite number of combination of possible setups and needs this is not something we can solve generically in our RTL without increasing the debug code size drastically.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • I guess we'll have to agree to disagree: I find it difficult to believe that the amount of flash used in tracking how much heap is in use is large versus the negative impact of not knowing that you've lost the much scarcer resource that is RAM. And heap checking, in my view, should be done on the target, in real scenarios, at which point you wouldn't be using a "test" malloc()ater because then you're not testing the real thing; practically speaking you'd just end up having to entirely replace the malloc() function SES provides with ones own, again kind of taking away from the usefulness of SES.

    Don't get me wrong, I really like SES from a GUI perspective: neat and fast, beats Eclipse and the like hands down.

    Just think it's missing an essential feature for those making production code.