Wednesday, 4 August 2010

valgrind

How did I live without valgrind? It so useful!

To be honest I am very careful with coding and rarely hit memory leaks. My background has been in embedded software which means being very careful.

However, we had a memory leak in the call handling code. Not serious, and picked up by our monitoring anyway. Just using up a few bytes every now and then so that after some days you could see it was using noticeably more memory.

Buggered if I can find it, so (at Cliff's suggestion) I tried valgrind. It is already installed on the machine as standard it seems. All I had to do was run the app with valgrind on the start of the command line; leave it a few seconds to "leak" a bit; stop it; and valgrind says where the leak is. It could not be simpler to use...

Knowing where to look - it was, of course, blindingly obvious. An exception case did not free something, but that was happening every time an authenticated SIP request came in.

So +1 for valgrind. Well worth using if you have any suspicion that you have a memory leak in your code. Very cool.

P.S. Apologies to my sister-in-law and other non-techies as this will have made no sense whatsoever and I really could not find a way to explain it in simpler terms, so didn't even try... :-)

4 comments:

  1. Then again you could use a language with garbage collection. :-) That would avoid problems with memory leaks and also the more serious problem where you carry on using memory that has been freed.

    For application level code on general purpose hardware, is there any reason to use C these days?

    ReplyDelete
  2. Come on - C is excellent :-)

    ReplyDelete
  3. thanks for the kind thoughts lol your followers must think what a thicko you have for a sister-in-law but i don't mind Im still your fav one ha ha x

    ReplyDelete
  4. PeteX, valgrind detects use-after-free as well. It also detects use-uninitialized on the *single bit* level. (And that's just the memcheck tool.)

    RevK, GCC's -fmudflap option might also be worth investigating. (See the GCC docs). It's a compile-time instrumentation option which (unlike valgrind) can detect overruns of stack-allocated objects. (It's not a security option, though, unlike -fstack-protector, not least because it's much too expensive.)

    (And, yes, valgrind is utterly sodding awesome. It's spotted many hundreds of bugs in the code I write at work and probably millions across the free software world. I recommend the valgrind paper, too, because the way it works -- dynamic decompilation to an instrumentable intermediate language, instrumentation, then recompilation again, all completely transparently to the user -- is incredibly nifty.)

    ReplyDelete