-3

i have a task in RTOS and inside task i have allocated memory for example 5 times and freed memory 3 times, but how to find memory leak without using external tools?

sam
  • 25
  • 4
  • if you have prints - try printing the allocated pointer right after the allocation (on each allocation operation) - and print the pointer before each `free` command. compare the results of the malloc and free and with some prints you might be able understand the flow where they are not released – Omer Dagan Feb 22 '18 at 12:37
  • @Dagan if task has many number of allocations and de-allocations, is it easy to find with print messages? – sam Feb 22 '18 at 12:44
  • it depends... not very easy but what i usually do is format the messeges in a specific way which is easy to parse. and then use a script to give me the un freed buffers. then one can go back to the full log and see where was the unhandeled allocation. If you want i can put an answer with such a script – Omer Dagan Feb 22 '18 at 14:14
  • 2
    If a task runs indefinitely, there is no way of detecting a "leak" because there is no way of determining automatically that any specific allocation will not at some point be free'd. For tasks that terminate, it would be possible to determine that not all allocated memory was deallocated on termination, but tasks do not normally operate that way. – Clifford Feb 22 '18 at 14:20
  • The limited ability to debug on embedded target is one of the strong reasons for doing code reviews/walkthroughs, and running comprehensive unit testing on your development host (perhaps even to the level of using a hosted RTOS simu/emulation) which not being memory constrained can be run with proper memory leakage monitoring. Yes it's work that if you wrote the code error-free you wouldn't have to do - but be realistic, you've already proved you can't write error-free code! And think of all the stress that proper testing removes. – DisappointedByUnaccountableMod Feb 22 '18 at 20:50
  • 2
    Using dynamic memory allocation on a RTOS system suggests a fundamentally poor program design. It is not a PC. So the leaks are the least of your problems. Solve this by writing a program that makes sense instead: use stack or memory pools etc. – Lundin Feb 23 '18 at 09:38
  • 1
    I completely agree with Lundin. This is exactly why experienced embedded folks avoid malloc and free (or new and delete) like the plague. It is usually outlawed in embedded coding standards. If you want something to survive beyond the scope it is in, use a global variable that is put on the heap at startup time once and only once or build your own mini-memory management system - an array with an in-use flag for each element. – Nerf Herder Feb 23 '18 at 18:24
  • Some compilers provide a debug log breakpoint which allows you to count how many times the codes pass through your log breakpoints while letting the program runs so you can count the `malloc()` and `free()` calls made in your codes. [IAR Making the best use of the available breakpoints](https://www.iar.com/support/resources/articles/making-the-best-use-of-the-available-breakpoints/) – ecle Mar 11 '18 at 10:03

1 Answers1

0

I don't think FreeRTOS maintains task ownership of allocations (a quick read of heap_2.c in a random local working directory supports this), so that sounds impossible.

There might be hooks that let you add this on your own, see the traceMALLOC() and traceFREE() macros.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • well your answer seems good, but using traceMALLOC() and traceFREE() is some extra task and it takes extra memory and CPU for processing right? is there any other method? – sam Feb 22 '18 at 12:50
  • 1
    You are not going to be able to measure what's going on without adding at least extra task time. – Ben Feb 22 '18 at 12:57