1

I'm working with embedded linux development, and we're currently having some trouble with some memory page allocation faults, which led me to believe we have a leak somewhere.

Currently, I am trying to cross compile valgrind to use on our system, but I'm losing my faith on this solution because of the sheer amount of memory valgrind will use up (we have serious memory restrictions).

This has made me wonder: is there any way of hunting for a memory leak without valgrind or with a valgrind-like application with minimal memory usage? Creating wrappers for malloc() and free() is out of question.

Also, the test that caused the allocation failures was a simple stress test of copying a file n times and checking its md5sum, in case anyone is curious.

I'm using the Linaro toolchain for cross compiling, glibc 2.15, and the system is set up without a swap partition. The system has around 64MB of RAM, making valgrind, or any other memory intensive application a tad difficult to use.

Regards, Guilherme

Guilherme Costa
  • 357
  • 3
  • 11
  • 3
    Why is wrapping / substituting `malloc()` and `free()` out of the question? You *do* know that Valgrind does that, do you not? – John Bollinger Jan 08 '16 at 16:20
  • 1
    If memory is in short supply, you might be suffering from [memory fragmentation](http://stackoverflow.com/questions/3770457/what-is-memory-fragmentation) rather than a leak. – Weather Vane Jan 08 '16 at 16:20
  • There's also AddressSanitizer if you don't like valgrind, but the principle of operation is the same. – kfx Jan 08 '16 at 16:21
  • 1
    What C library are you using? If GNU's, then you could consider setting up memory allocation logging via `mtrace()`. – John Bollinger Jan 08 '16 at 16:23
  • What I meant was that creating the wrappers 'manually' (i.e. writing them myself), is not what I'm seeking. – Guilherme Costa Jan 08 '16 at 16:26
  • 1
    I appreciate wanting to avoid rolling your own solution to a problem that has already been solved. If none of the available solutions are suitable, however, then you may have few alternatives. In any case, you have not given us enough information to determine which existing solutions are available to you. – John Bollinger Jan 08 '16 at 16:30
  • I've edited the description to be a bit more informative. Hope it helps :) – Guilherme Costa Jan 08 '16 at 16:43

1 Answers1

4

Since you are using glibc, you should have its built-in memory-tracing support available to you. Your program would enable this by calling mtrace(3) at or near startup. mtrace() installs hook functions into the memory allocator to log allocations and deallocations, under runtime control via environment variable MALLOC_TRACE.

You probably also want to be aware of mtrace(1), a Perl script for interpreting log files produced by the mtrace facility.

This facility traces only allocations and deallocations, which is much less than Valgrind does. Nevertheless, those are the main items of interest when you are looking for a memory leak.

John Bollinger
  • 121,924
  • 8
  • 64
  • 118