bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Certain display expressions cause gdb coredump, and displaying sbrk(0) d


From: Galen Menzel
Subject: Certain display expressions cause gdb coredump, and displaying sbrk(0) doesn't work
Date: Wed, 04 Apr 2001 02:06:07 -0500

Hi there.

I have noticed some strange behavior in gdb version 4.18 (compiled by redhat)
and version 5.0 compiled by me on my redhat 6.2 machine with egcs-2.91.66.  I
have been using gdb to debug a memory manager.  I wanted to keep track of the
current breakpoint (the one set by brk(), not the debugging one) of the process,
and so executed:

display sbrk(0)

However, the displayed value never changed, even when brk had just succeeded in
changing the breakpoint.  The following small program illustrates the problem:

#include <unistd.h>

int main() {
    char *brk_pt = sbrk(0);

    printf("Here's that brk_pt: %x\n", brk_pt);
    if (brk(brk_pt + 4))
        return -1;
    brk_pt += 4;
    printf("Here's that brk_pt: %x  %x\n", brk_pt, sbrk(0));
    return 0;
}

Here is a script of the program being run with sbrk(0) being displayed:

---------------------------------------------------------------
$ gdb -silent foo
(gdb) break main
Breakpoint 1 at 0x8048436: file foo.c, line 4.
(gdb) run
Starting program: /home/galen/tmp/foo 

Breakpoint 1, main () at foo.c:4
4           char *brk_pt = sbrk(0);
(gdb) display /x sbrk(0)
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) n
6           printf("Here's that brk_pt: %x\n", brk_pt);
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 
Here's that brk_pt: 8049624
7           if (brk(brk_pt + 4))
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 
9           brk_pt += 4;
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 
10          printf("Here's that brk_pt: %x  %x\n", brk_pt, sbrk(0));
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 
Here's that brk_pt: 8049628  8049628
11          return 0;
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 
12      }
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 
0x400329cb in __libc_start_main (main=0x8048430 <main>, argc=1, 
    argv=0xbffffaa4, init=0x80482e0 <_init>, fini=0x80484cc <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffa9c)
    at ../sysdeps/generic/libc-start.c:92
92      ../sysdeps/generic/libc-start.c: No such file or directory.
1: /x ({<text variable, no debug info>} 0x4000f7c0 <__sbrk>) (0) = 0x8049624
(gdb) 

Program exited normally.
(gdb) 
--------------------------------------------------------------------

As you can see, the value of the displayed sbrk(0) never changes, even the call
to brk has changed the break point; you can see in the output of the second
printf that the value of sbrk(0) should be 8049628, but is being displayed as
0x8049624.

Thinking that displayed function calls might not be evaluated each time they are
displayed, I changed the function I was calling from sbrk(0) to rand(), to see
if the value would change.  The behavior from gdb under these circumstances was
even more surprising -- after running completely once, a second call to run
makes gdb dump core.  Here's a script:

------------------------------------------------
$ gdb -silent foo
(gdb) break main
Breakpoint 1 at 0x8048436: file foo.c, line 4.
(gdb) run
Starting program: /home/galen/tmp/foo 

Breakpoint 1, main () at foo.c:4
4           char *brk_pt = sbrk(0);
(gdb) display rand()
1: rand () = 1804289383
(gdb) n
6           printf("Here's that brk_pt: %x\n", brk_pt);
1: rand () = 846930886
(gdb) 
Here's that brk_pt: 8049624
7           if (brk(brk_pt + 4))
1: rand () = 1681692777
(gdb) 
9           brk_pt += 4;
1: rand () = 1714636915
(gdb) 
10          printf("Here's that brk_pt: %x  %x\n", brk_pt, sbrk(0));
1: rand () = 1957747793
(gdb) 
Here's that brk_pt: 8049628  8049628
11          return 0;
1: rand () = 424238335
(gdb) 
12      }
1: rand () = 719885386
(gdb) 
0x400329cb in __libc_start_main (main=0x8048430 <main>, argc=1, 
    argv=0xbffffaa4, init=0x80482e0 <_init>, fini=0x80484cc <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffa9c)
    at ../sysdeps/generic/libc-start.c:92
92      ../sysdeps/generic/libc-start.c: No such file or directory.
1: rand () = 1649760492
(gdb) 

Program exited normally.
(gdb) 
The program is not being run.
(gdb) run
Starting program: /home/galen/tmp/foo 

Breakpoint 1, main () at foo.c:4
4           char *brk_pt = sbrk(0);
Segmentation fault (core dumped)
---------------------------------------------------------------------

Having gdb display clock() also makes it dump core.  Displaying printf("hello")
yeilds the following after the second run command is given:

----------------------------------------------------------------
(gdb) run
Starting program: /home/galen/tmp/foo 

Breakpoint 1, main () at foo.c:4
4           char *brk_pt = sbrk(0);
3: printf ("Hi") = 
Program received signal SIGSEGV, Segmentation fault.
Disabling display 3 to avoid infinite recursion.
0x8 in ?? ()
2: 4 = 4
The program being debugged stopped while in a function called from GDB.
When the function (at 0x8) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) display printf("Hi")
4: printf ("Hi") = 2
(gdb) n
Cannot find bounds of current function
(gdb) 
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/galen/tmp/foo 

Breakpoint 1, main () at foo.c:4
4           char *brk_pt = sbrk(0);
4: printf ("Hi") = Segmentation fault (core dumped)
--------------------------------------------------------------------

Anyway, that's about all for now.  Let me know if you need any more information.

Thanks.
galen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]