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].

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.

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: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.

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.

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 performance (the performance cost is smaller for cleaner programs, and can be improved further by holding CCured's hand on the parts of the program that it does not understand by itself). Using CCured we have found bugs that Purify misses with an order of magnitude smaller run-time cost.

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..."