Very Computer

I've looked high and low for references to analyzing core dumps and all
I can find is that "gdb will show you the statement at which it died".
But the core file must be more useful than that!  Any pointers to some
reference material on this gratefully appreciated.... thx.

Sent via Deja.com http://www.deja.com/
Before you buy.

Quote:>I can find is that "gdb will show you the statement at which it died".
>But the core file must be more useful than that!  Any pointers to some
>reference material on this gratefully appreciated.... thx.

  print var

and it will tell you the value of the variable.  this works for me
for variables in the current function when the program crashed.
i don't know how to print variables in calling functions, but i
imagine it can be done.

---
"... What with you being his parents and all, I think that you could
be trusted not to shaft him."  -- Robert Chang, rec.games.board

 chrisodd> I have a program that gets a segmentation fault after
 chrisodd> running for an extremely long time (like 4 days).  I've
 chrisodd> used gdb to determine the exact statement at which it died.
 chrisodd> However, I'd like to determine the state of some of the
 chrisodd> variables at that point.  Is there a way to do this using
 chrisodd> the core dump?

yes; all of gdb's normal facilities to inspect data should work.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

dbx also has similar facilities, in case you have it but not gdb.
Personally I prefer gdb, but some (weird) people use dbx...

--

Compugen Ltd.          |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.    |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555    http://3w.compugen.co.il/~ariels

The "help" command in gdb could (in my opinion) have been left out,
it's not that informative for a newcomer. A decent manpage would do
much better...

Quote:> I've looked high and low for references to analyzing core dumps and all
> I can find is that "gdb will show you the statement at which it died".
> But the core file must be more useful than that!  Any pointers to some
> reference material on this gratefully appreciated.... thx.
> Sent via Deja.com http://www.deja.com/
> Before you buy.

When I do a bt on the core dump, it shows the following:

(gdb) bt
#0  0xc0b7ed9 in memmove ()
#1  0x0 in ?? ()

memmove is called in only one place in my program, in a function called
deal_with_data.

Here's what the call stack should look like:
main->read_socks->deal_with_data->memmove()

Here's what the call to memmove looks like:
      memmove(currentbuffer,
             terminatorpos + strlen(terminator),
             usedbuffer - (terminatorpos - currentbuffer +
                           strlen(terminator)) + 1)

   **NOTE: via other methods I determined that it was my usedbuffer variable
that was incorrect and that's what was causing my segfault... so I've solved
the programming problem but I still want to figure out how to use gdb in
this situation.

If I try to look at the parms to memmove, it shows:
(gdb) p currentbuffer
No symbol "currentbuffer" in current context.
(gdb) p terminatorpos
No symbol "terminatorpos" in current context.
(gdb) p terminator
No symbol "terminator" in current context.
(gdb) p usedbuffer
No symbol "usedbuffer" in current context.

Doing "info variable" shows all the globals I've defined.  However, doing
info local shows the following:

(gdb) info local
No symbol table info available.

Also, if I do a print on the global variables, they all appear to be
unitialized...

examples:
(gdb) p port
$7 = 0
(gdb) p listeningSocket
$8 = 0

(Both are int's and are assigned right at the beginning of the program).

It's almost as if I'd invoked gdb WITHOUT the core file, except that the
backtrace shows the memmove, and when I invoke info frame, I get:

(gdb) info frame
Stack level 0, frame at 0x8047b18:
 eip = 0xc0b7ed9 in memmove; saved eip 0x33313937
 (FRAMELESS), called by frame at 0x8047b18
 Arglist at 0x8047b18, args:
 Locals at 0x8047b18, Previous frame's sp is 0x0
 Saved registers:
  ebp at 0x8047b18, eip at 0x8047b1c

(gdb) up
#1  0x0 in ?? ()
(gdb) info frame
Stack level 1, frame at 0x8047b18:
 eip = 0x0; saved eip 0x33313937
 caller of frame at 0x8047b18
 Arglist at 0x8047b18, args:
 Locals at 0x8047b18, Previous frame's sp is 0x0
 Saved registers:
  ebp at 0x8047b18, eip at 0x8047b1c

Any ideas what I'm doing wrong (not in the programming, but in the use of
gdb)?

it *should* work if you just "up" a context, but since your backtrace seems
garbage, that wouldn't help much.

Quote:> Also, if I do a print on the global variables, they all appear to be
> unitialized...
> examples:
> (gdb) p port
> $7 = 0
> (gdb) p listeningSocket
> $8 = 0
> (Both are int's and are assigned right at the beginning of the program).

anyway i'd try it again but with the source in a place that gdb can get at
it (e.g. in the cwd) and compiled with -ggdb3.  you'd be surprised how much
more useful gdb is that way.

--
             /"\                                m i k e    b u r r e l l

              X        AGAINST HTML MAIL
             / \

Quote:>Thanks for the responses... I guess my problem has more to do with USING
gdb
>(I thought possibly it wasn't able to inspect the states of variables in a
>dump due to the problems I describe below).  Anyway:

>When I do a bt on the core dump, it shows the following:

>(gdb) bt
>#0  0xc0b7ed9 in memmove ()
>#1  0x0 in ?? ()

Rob