Re: Using gdb
From: Andrei Voropaev (avorop_at_mail.ru)
Date: 26 Aug 2004 11:31:57 GMT
On 2004-08-26, Doru-Catalin Togea <email@example.com> wrote:
> I have a set of client server programs. I can choose if I want to use TCP
> or UDP to send data from the server to the client. The server sends
> lots of data, right now I have a datarate of 6.9 Mbits/sec sent in 30
> packets/sec. Using TCP seems to work fine, for indefinite periods of time.
> Using UDP crashes my program (Segmentation fault) after a few seconds,
> roughly after 100 calls to "write" have been made to the UDP socket.
> The program dumps core, and when I run "gdb prog core" command it stops at
> the line where it crashes. It is usually a line from libc or some other
> library. This I have found out by looking at the output of "where" in gdb.
Usually if crash has happened inside libc or some other "standart"
library, then it means that the program corrupts the memory. And it also
means that gdb won't help much because it can't tell you where you
corrupted the memory. Try to use one of these to discover your problem
I find valgrind especially helpful.
Also do search on google for "memory debugging". You may find some
> But I wonder what else can I do to debug my program? There seem to be
> zillions of commands available in gdb. Is there a good tutorial?
Everything depends on which particular problem you have to resolve. And
usually it means that you have to do a lot of next and step.
> Also how should I procede? Running "gdb prog core" will run the programme
> until the crash, but wouldn't it be usefull to somehow stop the programme
> right before the crash? The crashes happen in two places, as far as I
When you run gdb with core file then it does not run your program. It
just displays the state of the program at the moment when core was
dumped. If you want to stop before that happens, then start your program
without core, setup breakpoint in desired position in your code and then
> know, but not always after the same number of iterations. I could set
> break-points before the crash lines, but this would imply a lot of nexting
> (and maybe stepping) until the crash occurs.
That's the nature of bugs :) If they were obvious then probably there
wouldn't be any :) So, if none of memory debuggers help then you'll have
to do a lot of stepping and checking/watching a lot of variables/memory