1

I know this is hardly a new question, but I haven't found anything elsewhere that works. I've got a C program that steadily eats memory as it runs - I use the 'free' command to track it, and I can see the amount of available memory is decreasing as long as it executes, which shouldn't be happening. However, I can't find anything in the program itself that could be causing this. I've also tested it with valgrind and dmalloc, and nether of them are able to detect any memory loss.

How do I find the leak?

Benubird
  • 18,551
  • 27
  • 90
  • 141
  • Are you sure you are not including buffers in the amount of used memory? If your program reads files etc this can cause a steady increase there, but that memory is not really “in use” in the sense that it would become unavailable to other applications. – Arkku Nov 19 '10 at 11:40
  • I'm pretty sure. I first noticed this after I left the program running for two days, it filled up all the memory and crashed. – Benubird Nov 19 '10 at 13:10

2 Answers2

3

If you're sure about your usage of memory, perhaps it's not your mallocs and frees that are the problem.

If you're using any libs, you should double-check that you use them correctly. Many have initialisation and freeing functions that you can easily forget, and thus cause memory leak(s).

Raveline
  • 2,660
  • 1
  • 24
  • 28
  • On further investigation this was the case - tdelete was not freeing the memory used by the tree, as I expected it to. – Benubird Nov 25 '10 at 10:59
3

Is the memory actually leaked, or does the program simply consume more memory the longer it runs? In other words, is the program perhaps building a large dynamic data structure (linked list, etc) that simply continues to grow? As long as the program has a pointer to the memory it's not really a leak - but if the allocations are never freed each new one will get more memory from the OS. That would also explain why the tools you used reported no "leaks".

When I've had to do this I've done things like write a log message to a flat file every time my program allocated memory and freed it. The messages would include things like filename and program line where the memory was allocated and the address returned from malloc when allocating memory, or likewise the filename and program line where the memory was being freed and the address of the buffer being freed. Then you can sort the resulting file by address, and those addresses with an "ALLOCATE" message but no "FREE" message are the ones that may have leaked - or at least weren't freed by the time the program terminated. This can be time-consuming to implement and automated tools are nicer if you've got them - but depending on your circumstances you may have to do something like this.

Or, you might want to just punt and use a garbage collector. The Boehm collector might work for you - take a look at http://www.hpl.hp.com/personal/Hans_Boehm/gc/.

Share and enjoy.

Bob Jarvis - Слава Україні
  • 48,992
  • 9
  • 77
  • 110
  • The OP could also try using the `massif` Valgrind tool (rather than the default `memcheck`), which is a heap profiler. It account total allocated memory to the part of the program that allocated it, which should allow you to pinpoint where the memory is being used. – caf Nov 19 '10 at 13:12
  • @caf - I believe that the OP noted that he'd already tried valgrind and dmalloc. – Bob Jarvis - Слава Україні Nov 19 '10 at 13:13
  • The OP mentioned using Valgrind to look for memory leaks, which implies that they used the `memcheck` tool. Valgrind is actually a package of several different tools, and I'm suggesting to use the `massif` heap profiler instead (which doesn't look for leaks, but profiles memory usage), based on the idea that it's not really a "leak" in the classic sense at all. – caf Nov 19 '10 at 13:52
  • I would argue that the distinction in your first paragraph is incorrect/backwards. A single `(void)malloc(1000);` (performed once or even a bounded number of times) is *not* a memory leak in my book, whereas progressively larger memory usage over the program's lifetime *is* a memory leak unless it's tied to a specific demand from the user and can be reversed by some operation performed by the user. – R.. GitHub STOP HELPING ICE Nov 19 '10 at 15:05
  • I did only use memcheck, but after this suggestion I went back and tried massif - no joy. I'm now trying Bob's idea of printing out allocate and free messages - hopefully that will get somewhere. Best idea I've heard so far, at any rate. – Benubird Nov 19 '10 at 15:36