GDB dumping stack frames by address incorrectly?

Hello again -current,

Looks like I've run into a debugger bug... Consider debugging a simple
program:

: $ gcc -g -o c c.c
: $ gdb c
: ...
: (gdb) br main
: Breakpoint 1 at 0x80484a8: file c.c, line 4.
: (gdb) r
: Starting program: /home/df/freebsd-bugs/c
: Breakpoint 1, main () at c.c:4
: 4               return 0;
: (gdb) info frame
: Stack level 0, frame at 0xbfbfeb90:
:  eip = 0x80484a8 in main (c.c:4); saved eip 0x80483d6
:  source language c.
:  Arglist at 0xbfbfeb88, args:
:  Locals at 0xbfbfeb88, Previous frame's sp is 0xbfbfeb90
:  Saved registers:
:   ebp at 0xbfbfeb88, eip at 0xbfbfeb8c

Here, everything is normal; notice the frame pointer is 0xbfbfeb90.

: (gdb) help frame
: Select and print a stack frame.
: With no argument, print the selected stack frame. (See also "info frame").
: An argument specifies the frame to select.
: It can be a stack frame number or the address of the frame.
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
: With argument, nothing is printed if input is coming from
: a command file or a user-defined command.

After reading the above, one would expect that 

: (gdb) frame 0xbfbfeb90

would print out the same frame. However, it shows this:

: #0  0x00000000 in ?? ()

Moreover,

: (gdb) info frame 0xbfbfeb90
: Stack frame at 0xbfbfeb90:
:  eip = 0x0; saved eip
: /src/usr.src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/dwarf2-frame.c:613: internal-error: dwarf2_frame_cache: Assertion `fde != NULL' failed.
: A problem internal to GDB has been detected,
: further debugging may prove unreliable.
: Quit this debugging session? (y or n) n
: 
: /src/usr.src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/dwarf2-frame.c:613: internal-error: dwarf2_frame_cache: Assertion `fde != NULL' failed.
: A problem internal to GDB has been detected,
: further debugging may prove unreliable.
: Create a core file of GDB? (y or n) y
: (gdb) The program is running.  Exit anyway? (y or n) y

The stack trace of stock gdb is unlikely to help, but here goes:

#0  0x283ad75b in kill () from /lib/libc.so.7
#1  0x283ad6f8 in raise () from /lib/libc.so.7
#2  0x283ac408 in abort () from /lib/libc.so.7
#3  0x080bad56 in query ()
#4  0x080baef0 in internal_verror ()
#5  0x080baf14 in internal_error ()
#6  0x0813690f in dwarf2_frame_base_sniffer ()
#7  0x08136966 in dwarf2_frame_base_sniffer ()
#8  0x08084d40 in frame_register_unwind ()
#9  0x08084f58 in frame_unwind_register ()
#10 0x0814c242 in i386_register_name ()
#11 0x08084c60 in frame_pc_unwind ()
#12 0x080ec048 in parse_frame_specification ()
#13 0x080c793b in execute_command ()
#14 0x0808a012 in async_disable_stdin ()
#15 0x0808a657 in async_disable_stdin ()
#16 0x28275360 in rl_callback_read_char () from /lib/libreadline.so.6
#17 0x080899ab in _initialize_gdbarch_utils ()
#18 0x0808b364 in delete_file_handler ()
#19 0x0808ae1a in gdb_disable_readline ()
#20 0x0808b5c9 in gdb_do_one_event ()
#21 0x080c7478 in throw_exception ()
#22 0x080c75c2 in catch_errors ()
#23 0x0815508b in _initialize_varobj ()
#24 0x08071f4a in current_interp_command_loop ()
#25 0x0807114b in main ()

I've just tried with -current of around December 2005, and the behavior
is the same. Is it intended?

-- 
DoubleF
No virus detected in this message. Ehrm, wait a minute...
/kernel: pid 56921 (antivirus), uid 32000: exited on signal 9
Oh yes, no virus:)