Tools for Debugging Stack Corruption? 30
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 (Score:4, Informative)
Boehm Garbage Collector (Score:3, Informative)
CCured (Score:3, Informative)
Re:Electric Fence (Score:1)
A Couple Of Tools (Score:5, Informative)
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 (Score:4, Informative)
There are obviously several alternatives. (Score:5, Informative)
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. (Score:3, Informative)
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. (Score:2)
Re:There are obviously several alternatives. (Score:2)
Re:There are obviously several alternatives. (Score:2)
All good suggestions, but not for stack (Score:5, Informative)
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 (Score:2)
i'm going to try to arrange to send them a set of object files which can
$your_os_of_choice !?! (Score:1)
I don't like yourOsOfChoice style naming, so I'll give you that...
Purify (Score:2)
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 (Score:2)
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 (Score:2)
Ultimate solution (Score:2, Redundant)
Re:Ultimate solution (Score:2)
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 (Score:2)
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
Yes,
Re:Ultimate solution (Score:2)
probabilistic memory safety (DieHard) (Score:2)
http://www.cs.umass.edu/~emery/diehard [umass.edu]
-- emery
gcc -fbounds-check (Score:1)