0

I'm tring to predict memory leak in an linux c++ programme.

The programme is an network server which fork a lot of sub-process to handle request.

I can get the RSS of the process after it handled one request, and I want to make the process kill itself if it find out that there could be memory leak.

I can make the process kill itself if it's RSS is bigger than an configured value ( like 1GB ), but this seems too simple and this value is also not easy to configure.

I can also make the process kill itself if the RSS is bigger and bigger for N times (like 100), but this seems not proper too, if the process cache some datas.

Is there any memory leak prediction algorithms?

I have googled it, but can't find one.

Thanks.

Sorry for not makeing the question clear.

Actually I'm not trying to find some way to find how the memory leak, I know there is tools like valgrind.

The situation is like this:

The programme I worted is an RPC framework, there is a father process, which will fork lots of sub-processes.

These sub process will run some business logic code which is not written by me and I have no control of these codes.

When these logic codes leak memory, the sub-process will be killed by the os OOM Killer.

But at that point, due to lack of memory, the os will halt for a while (minutes or even more ) or even breakdown and we will have to reboot the system.

I want to avoid this situation by predict the memory leak of the logic codes and make the sub-process kill itself before the OOM Kill do it's job.

And if the sub-process kill itself, the father process will fork another sub-process to run the logic code.

I can get the memory occupied by the sub-process after it handle one request.

So the simplest way is to check if the sub-process occupy too much memory than an pre-configured value (like 1GB), if it is, then make it kill itself.

But this algorithm seems too simple and the value is not easy to configure.

So what I'm finding is an algorithm to predict that if there is memory leak in an process.

Thanks

SSolid
  • 135
  • 1
  • 3
  • 11
  • 5
    Prediction: The probability of a memory leak approaches 1 as the C++ program approaches completion. – Arkku Feb 24 '14 at 12:52
  • The best way is to prevent memory leaks, not to predict. Also, if the process will kill itself, what's the point? If out-of-memory happens, it will (most probably) crash, no matter what. _OR_, you're talking about something else, not for real memory leak. – Kiril Kirov Feb 24 '14 at 12:52
  • 1
    possible duplicate of [How to Test for Memory Leaks?](http://stackoverflow.com/questions/420599/how-to-test-for-memory-leaks) – DevSolar Feb 24 '14 at 12:57
  • 1
    not all memory leaks are necessary evil. blindly killing the application can do more harm than good. – Karoly Horvath Feb 24 '14 at 13:18

4 Answers4

5

You can't predict memory leaks (it probably can be proved equivalent to the halting problem).

You could measure or instrument the binary, notably with valgrind (which will only tell you if some particular execution has leaked).

You could also consider using Boehm's conservative garbage collector. It would usually free memory automatically (but there is no guarantee since it is a conservative garbage collector!).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
1

Without further constraints, no there isn't. The program could do anything and as a result have what ever kind of pattern in its memory use. Tools like valgrind can detect memory leaks, for example by tracking each memory allocation and noticing when there is a piece of allocated memory which is not reachable. But they are essentially running the program in a VM or under debugger, which a huge performance penalty, so not a solution for production use memory leak detection.

Solution is really to not leak memory, to find memory leaks while still developing the software. There you can use tools like valgrind, combined with enough test cases, to catch all leaks. But best is to do high quality software. Memory leaks are result of either bad methodology, or sloppy implementation.

As a practical solution to problem itself: Do not try to detect memory leaks. Just restart the process for example once per 24h, at the time where it causes least disruption. Of course this is a bit "ugly", it encourages just ignoring some bugs when they should be fixed for example. This is a case of "ugly reality vs. sound engineering principles".

hyde
  • 60,639
  • 21
  • 115
  • 176
1

I'm tring to predict memory leak in an linux c++ programme. [...] Is there any memory leak prediction algorithms?

No, there is no algorithm. This depends on the developer's good or bad habits. That means, if you wrote ten applications and they all had memory leaks, you can predict that your 11th one will have memory leaks (i.e. there is 1 chance in 11 that your app will not have memory leaks).

This looks to me like the x-y problem. If you have child processes with memory leaks, the proper solution would be to remove the memory leaks, from the child processes. Otherwise, you can impose a limit in your system (i.e. no child process will consume more than 350Mb of memory"). This limit though is in no way connected to memory leaks.

To detect memory leaks in your development process, consider using a specialized tool (like valgrind or BoundsChecker).

utnapistim
  • 26,809
  • 3
  • 46
  • 82
  • 1
    +1 for *if you wrote ten applications and they all had memory leaks, you can predict that your 11th one will have memory leaks* :-D – hyde Feb 24 '14 at 17:57
0

One way to deal with memory leaks is to implement reference counting. The idea is to have for each object or struct, a count of how much pointers are pointing to it, when this count drop to 0 free the allocated memory. This forces you to rethink the code, but it is effective when several objects are pointing to another object and cannot predict when it will become useless.

If you are programming in C++, you could try boost libraries, they have implementation of smart pointers for reference counting.

http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/smart_ptr.htm

OAnt
  • 131
  • 1
  • 4
  • FYI, C++11 has usable smart pointers too, and at this point in time they are probably much better choice (for portability etc), than using older *boost* versions. – hyde Feb 24 '14 at 17:56