25

I've been asked to maintain a large C++ codebase full of memory leaks. While poking around, I found out that we have a lot of buffer overflows that lead to the leaks (how it got this bad, I don't ever want to know).

I've decided to removing the buffer overflows first. To make my bug-hunting easier, what tools can be used to check for buffer overruns?

MrValdez
  • 8,515
  • 10
  • 56
  • 79

14 Answers14

28

On Linux I'd use Valgrind.

diciu
  • 29,133
  • 4
  • 51
  • 68
  • Interesting. I'll see if this codebase can compile on Linux once I can't think of anything else to fix (although, I highly doubt it). Upvoted because someone else might find your answer useful. – MrValdez Oct 03 '08 at 14:44
  • It's a bit of an overkill just for buffer overflow ... – PierreBdR Oct 03 '08 at 14:45
  • 2
    Buffer overflow is a very nasty bug because the effects are not necessarily close to the cause (i.e. it can crash 500 lines later). If the stack gets smashed you'll need all the help you can get debugging. This is where Valgrind shines - it traps the overflow as soon as it happens. – diciu Oct 03 '08 at 14:53
  • There are frontends to valgrind, like kcachegrind that make it more usable. – hayalci Oct 03 '08 at 15:08
  • Valgrind might be a slight overkill for buffer overflows, but the original question mentioned the program being full of memory leaks. Valgrind should help with quite a few other memory problems as well. – Caleb Huitt - cjhuitt Oct 03 '08 at 16:30
  • Theres nothing wrong with using valgrind even if it _is_ overkill, You get a lot of extra error checks like use of un-initialized memory. – ideasman42 Oct 07 '12 at 05:38
  • valgrind is my go-to tool for overflows, what else would you use to find it?? – paulm Apr 15 '16 at 08:04
  • Valgrind does *not* catch simple buffer overflows like sprintf of 12 characters to a 10-character buffer. – bu11d0zer Nov 22 '16 at 00:58
10

Consider using more modern data structures as a way of avoiding buffer overflows. Reading into a std::string won't overflow, and std::vectors are much safer than arrays. I don't know what your application is, and it's possible that raw buffers are used because you need the speed, but it's more common that they are used because that's what the original programmers were comfortable with.

Searching for memory leaks with the tools mentioned is a good idea, but they may not find all potential leaks, while using standard strings and container classes can eliminate problems you didn't realize you had.

David Thornley
  • 56,304
  • 9
  • 91
  • 158
8

IBM's Purify will do this, you run your app under it and it will give you a report of all errors (including other ones).

To kill memory leaks, use UMDH - run your app, take a snapshot of the memory, run it again, snapshot and then use a diff tool to see the allocations made since the first run through (note you must run your app once, and take snapshots as best you can).

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
4

Check on electric-fence, it is design just for buffer overflow ! It does not slow down the code itself (but slow down allocation/deallocation). It works and linux and windows.

It works by adding a segment with no read or write access before and after each allocated space. Trying to access this memory end up as a segmentation fault on UNIX and a memory violation (or something similar) on Windows.

PierreBdR
  • 42,120
  • 10
  • 46
  • 62
  • Sources are [here](https://code.google.com/p/electric-fence-win32/). Apparently it's been superceeded by [DUMA](http://duma.sourceforge.net/) – Fake Name Aug 12 '15 at 18:04
3

I'm surprised no one's mentioned Application Verifier (free!) on Windows. Visual Leak Detector (mentioned in another answer) is absolutely amazing for tracking many types of memory leak, but Application Verifier is top dog for tracking memory errors like buffer overruns, double frees, and buffer use after free (plus many, many more).

Edit: And it's very, very easy to use.

Sam Harwell
  • 97,721
  • 20
  • 209
  • 280
  • Nice ! But runtime based. With a large code base *(written in C in ly case)* you will mainly test your program for the way it had been designed. An attacker can the several thousands required hours at reading the code in order to find a memory leak exploit. I would have expected an automated tool for source code analysis similar to what exist for JavaScript. – user2284570 Oct 02 '15 at 13:47
3

The problem with /GS is it won't actually scan for bugs. It will just alert you after the fact. It seems like you are looking for a tool which will scan your existing code for potential buffer over/under runs.

A good tool for this, and other defects, is the Microsoft PreFAST tool.

Information here

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
3

MS:

Roskoto
  • 1,722
  • 1
  • 16
  • 27
  • Nice ! But runtime based. With a large code base *(written in C in ly case)* you will mainly test your program for the way it had been designed. An attacker can the several thousands required hours at reading the code in order to find a memory leak exploit. I would have expected an automated tool for source code analysis similar to what exist for JavaScript. – user2284570 Oct 02 '15 at 13:47
2

My vote goes to Rational Purify. Extremely powerful with a price to match. Makes short work of lots of problems and can really pay for itself. Also, is available on most *nix. Not sure about Windows, though.

Mark Kegel
  • 4,476
  • 3
  • 21
  • 21
2

The BoundsChecker component of Compuware's Devpartner does this very well in terms of dynamic execution. For static testing, I'd recommend pc-lint and flex-lint coupled up to Riverblade's visual lint for usability and reporting. If you have been handed a new code base, I'd recommend starting out with static analysis with reasonably loose rules so you catch just the nasty stuff. As the codebase improves you can tightent the rule set.

If you need to do this on Windows Mobile / Windows CE, check out Entrek's code snitch

Another tool to consider if the code makes it into the field is AQtrace, which basically analyses crashes on user machines and sends you the details. (Just in case all that boundchecking, purifcation, linting, valgrinding etc.. misses something)

SmacL
  • 22,555
  • 12
  • 95
  • 149
2

My company, Semantic Designs is looking for beta testers for a runtime memory safety checker (including buffer overruns) that detects all types of memory access violations, even those that valgrind and Purify cannot. This is presently for Windows C programs only, not C++ or other OSes.

EDIT June 1, 2011: The CheckPointer tool has gone production. Still C/Windows only. Handle multiple C dialects: MS Visual C, GCC 3/4.

EDIT May 5, 2012: CheckPointer now handles C99, including checking calls on the standard C and C99 libraries.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
1

Visual Studio has a /GS compiler flag that adds buffer overflow protection. Are there any others?

MrValdez
  • 8,515
  • 10
  • 56
  • 79
1

You can try Visual Leak Detector - I used it myself, and it is the first thing I'd recommend for mem-leak detection.

Paulius
  • 5,790
  • 7
  • 42
  • 47
1

I'd recommend the free "leakfinder" tool on the CodeProject by Jochen Kalmbach. See my post for more details on this thread (and the other answers) on this memory leak question

Community
  • 1
  • 1
John Sibly
  • 22,782
  • 7
  • 63
  • 80
0

On Windows for memory leaks/buffer overruns and other runtime error detection you can use:

I think they worth their price if you have large projects that need cleanup.

Dan Cristoloveanu
  • 1,974
  • 1
  • 13
  • 20