Tools for Debugging Stack Corruption?

blackcoot asks: "I know that there are tools which exist on hardened Linux distros and OpenBSD (and probably $your_os_of_choice too), which are designed to help track down stack corruption (which is often symptomatic of buffer overruns). Unfortunately, that's about all I know about those tools. What options are there? How effective are they? What does it take to get access to those tools? Are they really useful enough to make the effort justified?"

"My goal here is to increase my effectiveness at hunting down memory bugs, not necessarily to produce bullet proof, secure production quality code — the bugs I'm dealing with are, I believe, largely in software delivered by a subcontractor who swears they test their code and can't reproduce my bugs. What I really want is to a) demonstrate to them that a problem does, in fact, exist; b) demonstrate that the problem exists inside their code; and c) give them the tools they need to find, repair, and verify that the bug is no longer an issue.

First prize in my mind would be a Valgrind like tool which only requires trivial changes to the build process, but I'm pretty open to suggestions. If I have to run a hardened Linux to make this all possible, suggestions on pretty leading edge distros with reasonable automagic self configuration and hardware detection + laptop support would be greatly appreciated. Thanks much!"

Electric Fence

[sleepingsquirrel]

See Electric Fence [perens.com] and your documentation for debugging malloc [gnu.org].

Boehm Garbage Collector

[sleepingsquirrel]

Also, you can use the Boehm garbage collector as a leak detector [hp.com].

CCured

[sleepingsquirrel]

Also, something I've never tried, but always been interested in is CCured [berkeley.edu]...

CCured is a source-to-source translator for C. It analyzes the C program to determine the smallest number of run-time checks that must be inserted in the program to prevent all memory safety violations. The resulting program is memory safe, meaning that it will stop rather than overrun a buffer or scribble over memory that it shouldn't touch. Many programs can be made memory-safe this way while losing only 10-60% run-time perform

Re:Electric Fence

[c0nst]

Electric Fence can only detect heap corruption, but I think the submitter meant memory corruption of any kind. Valgrind can detect both.

A Couple Of Tools

[BusDriver]

You don't have to run a whole new distro!

First of all, there's libsafe [avayalabs.com] which is just a simple compile and install. Seeing as we don't know much about your specific problem, I'm not sure if it'll help.

Second to try is compiling your own custom kernel with the GrSecurity [grsecurity.net] kernel patch. It has as part of it the PaX [grsecurity.net] kernel patch which is very effective at protecting against overflows. You could even just install the PaX kernel patch itself, but I believe the version in GrSecurity is kept more up-to-date. You can compile it with protection turned off by default, but using the PaX tools turn on protection for just the binaries you wish to check.

Installing either (or both) of these could well help you, without the need to blow away your current install and start fresh.

Re:A Couple Of Tools

[sleepingsquirrel]

If I had to guess, I'd say most likely his problem is caused by fence-post type errors in dynamically allocated arrays (malloc and friends). But on the off chance he's got problems with buffer overruns caused by user input (gets, etc.) there's also stack protectors [wikipedia.org] like ProPolice [ibm.com] in addition to libsafe.

There are obviously several alternatives.

[Z00L00K]

As stated, Valgrind and Electric Fence are two alternatives. I would also like to point out Purify [ibm.com] (now owned by IBM) which I have been using from time to time. Of course the catch with that tool is that it's commercial, but you should at least evaluate it.

Using a complete hardened Linux distro is not necessary for "normal" development work, but it may be a good idea to verify that your application actually works there too.

In addition to the run-time checkers you can also look for static checkers like Splint [splint.org]. It can provide you with some extra information about potential problems that only occurs under certain conditions that maybe aren't met during runtime.

If the effort of trying to track down stack corruption is worth it? - YES! Absolutely! Catching bugs in an early stage is essential to keep down the lifecycle cost of a system. Also consider the risk of badwill if your product is prone to strange behavior and crashes.

Re:There are obviously several alternatives.

[pthisis]

The OP was asking for stack debuggers, which are much less common and generally come as intrusive compiler patches. libsafe is the best alternative.

ElectricFence, valgrind, Boehm GC, Purify, etc are all heap debuggers (for finding problems with overruning malloc'd memory, memory leaks, etc). It's possible that Purify has stack debugging capability these days, I'm not sure.

Re:There are obviously several alternatives.

[Eric Sharkey]

Valgrind can debug problems with both the stack and the heap.

Re:There are obviously several alternatives.

[blackcoot]

unfortunately valgrind isn't quite finely grained enough to localize stack corruption as it happens. it picks up on obscenely large jumps in the stack pointer, but doesn't detect whether addresses are "correct" relative to the stack frame. of course, how hard that is to do is a function of the abi and the architecture (if you do all your arithmetic on the stack this could be very problematic). it's probably not really tractable, now that i think about it.

Re:There are obviously several alternatives.

[jesup]

Another heap debugger (not stack) well worth using is dmalloc http://dmalloc.com/ [dmalloc.com]. Works in non-MMU embedded environments too; very configurable; checks for write-after-free, etc.

All good suggestions, but not for stack

[kbielefe]

The replies I have seen so far have all been excellent suggestions for detecting buffer overflows on the heap. Adequate stack protection actually requires the code to be compiled with a compiler that adds extra checks to each function call. This page [ibm.com] has more information on making gcc do what you want. Gentoo is very easy to set up for it, FYI, but it should be possible on any *nix distro without any kernel changes.

I feel your pain about bugs in libraries that you must use without the source code. I had an arrangement like that for nearly two years with extremely buggy code. Just relinking the static library with changes to my code, changing where in memory the library would reside, would often cause huge problems. Let's just say I got really good at debugging in assembly with gdb. I got where I could call them up and say something like, "you have some code at the end of function foo that looks like 'a[2] = b', but a was never allocated." They'd always reply with something like, "Yes it is ... oh wait..."

Re:All good suggestions, but not for stack

[blackcoot]

i really, /really/ want to avoid the assembly route if at all possible. first, i have a healthy dislike of assembly. but more importanty, analyzing the assembly requires some reverse engineering which has the potential to land me in all sorts of trouble. our collaborators on this particular project are potential competitors on other projects (my company is in a rather small niche), which is why neither of us has the complete code base.

i'm going to try to arrange to send them a set of object files which can

$your_os_of_choice !?!

[chroot_james]

Excuse me! I don't have $ in front of my variables!

I don't like yourOsOfChoice style naming, so I'll give you that...

Purify

[wfeick]

If you don't mind spending money, get Rational Purify from IBM. They seem to properly support Linux now, and they are the gold standard. You can download a 2 week evaluation license to give it a try.

As far as your build process, you just take whatever your link command is, and tag "purify" on the beginning of it. The tool will instrument all compiled objects that you are linking in, and produce a binary that does all sorts of really useful checking (read/write of freed memory, buffer overruns, memory leak

Re:Purify

[pthisis]

If you are developing software for money, there is nothing better.

I've found ccured more consistently finds problems than Purify. Plus it's faster, and free. It's also much harder to set up to work with large projects. So better in some significant ways, and worse in other significant ways. (also it doesn't find leaks but Boehm works fine for that).

Re:Purify

[blackcoot]

i suppose that ccured doesn't handle c++. personally, i've got nothing against spending money to get the right tools to solve the problem. whatever gets me from showstopper bugs to running stablely for indefinite amounts of time quickest is the path i'm interested in.

Ultimate solution

[Nutria]

Don't use C!

Re:Ultimate solution

[blackcoot]

i'm using c++, so i guess that means i'm using c too. it's not difficult to avoid about 99.99% of memory bugs in c++ by judicious use of the stl, avoiding dynamic allocation wherever possible, asserting that indices are always in bounds, etc.

unfortunately, the folks supplying the code do not use those techniques and i don't have the luxury of re-educating them.

as for why i'm using c++: implementing about 95% of this particular application in any language that isn't compiled to machine code with a darn good

Re:Ultimate solution

[Nutria]

FORTRAN? Ada? Pascal?

Their GCC optimization probably isn't that hot, though.

One of the really nice things about VMS is the Common Language Environment. This makes it possible to create executables out of object files written in multiple languages: C, Bliss, Macro/Asm, BASIC, COBOL, FORTRAN, Ada, etc. All of the language parsers create an intermediary language which the GEM common backend code generator takes and uses to build .obj files.

Yes, .NET does that, and so does GCC 4, to a degree, but VMS has ha

Re:Ultimate solution

[blackcoot]

all good languages. pity i don't speak them. intel's compilers are pretty darn good at optimization (you pretty much get about 10-15% speed up v. gcc with a recompile, more if you're willing to throw more disk space and time at the problem and more still if you link in their math and image libraries). it's not free, but it's cheap enough that it doesn't have to save much time before it's paid for itself.

probabilistic memory safety (DieHard)

[Ristretto]

You may find DieHard useful, if heap errors are also a problem -- it's a plug-in replacement for malloc/free that provides probabilistic guarantees of correct execution in the face of errors.

http://www.cs.umass.edu/~emery/diehard [umass.edu]

-- emery

gcc -fbounds-check

[nnorwitz]

gcc -fbounds-check could find some memory problems (and some non-problems). I used this feature over 6 years ago before it was integrated into gcc. YMMV.