From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Debugger that can detect buffer overruns? Date: 20 Nov 2000 13:08:13 GMT Organization: Aachen University of Technology (RWTH) Lines: 39 Message-ID: <8vb7nt$ltd$1@nets3.rz.RWTH-Aachen.DE> References: <8v3s96$ssh$1 AT nnrp1 DOT deja DOT com> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 974725693 22445 137.226.32.75 (20 Nov 2000 13:08:13 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 20 Nov 2000 13:08:13 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com dcasale AT my-deja DOT com wrote: > I don't know. Maybe I'm just having trouble understanding the GDB > documentation. Maybe it _does_ check for buffer overruns and I don't > know how to use that feature. GDB cannot really check for buffer overruns, simply because it doesn't know about all possible buffers that exist in the program, or about the places beyond their ends that are going to be overrun. Checking for buffer overruns requires instrumentation of the code being produced by the C compiler. GCC can add such instrumentation, in it's more recent releases. There's an extension package to GCC called 'checker' that makes use of that (and some other tricks) to provide full-scale memory access checking, but that's not been ported to DJGPP. When I once had that one working on my Linux box, it proved quite useful. It warns about reading unitialized data values both on the heap and the stack, about calling functions with illegal arguments, and lots of other things. It also contains malloc() debugging, but I have my doubts that your particular application is really having its problems on the malloc() front. For now, I usually bring my code to an Alpha box and use a tool provided by Digital, called "third degree", that does this type of memory access checking for me, and quite successfully, too. > I just ran a test with my compression program (without using YAMD) to > see whether it would always fail in exactly the same spot. After > failing with a "General Protection Error" on one particular delete, I > ran the _exact same code_ again, after a system reboot, and it failed > on a different delete. That's almost certainly not originally a problem of buffer overrun, then, but rather one of using uninitialized data. The 0xdeadbeef _crt0 option in DJGPP may help to more easily provoke one of those to show up its ugly head. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.