[Bug backtrace/8864] selecting a frame by its address does not work

[Bug backtrace/8864] selecting a frame by its address does not work

[naaaag at gmail dot com]

------- Additional Comments From naaaag at gmail dot com  2009-01-10 07:04 -------
It works , rather there can be a misunderstanding w.r.t 'ADDR'. The address
needs to be the frame address, rather than the frame pc : 

(top-gdb) where
#0  f3 () at test1.c:1
During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at
0x4004fc.
#1  0x0000000000400539 in f2 () at test1.c:2
#2  0x0000000000400558 in f1 () at test1.c:3
#3  0x0000000000400577 in main () at test1.c:7
(top-gdb) frame 1
#1  0x0000000000400539 in f2 () at test1.c:2
2       void f2() { printf("In f2 \n"); f3(); }
(top-gdb) p/x $rbp
$1 = 0x7fbffff730
(top-gdb) frame 3
#3  0x0000000000400577 in main () at test1.c:7
7         f1();
(top-gdb) p/x $rbp
$2 = 0x7fbffff750
(top-gdb) frame 0x7fbffff730
#0  f3 () at test1.c:1
1       void f3() { printf("In f3 \n"); sleep(15); }
(top-gdb) frame 0x7fbffff750
#2  0x0000000000400558 in f1 () at test1.c:3
3       void f1() { printf("In f1 \n"); f2(); }

Hence can consider this as a document issue. 

But it has a problem with non-frame addresses.  In parse_frame_specification_1 (
during frame selection ), when the frame number or frame address doesn't match ,
it goes for a default frame creation : 

    862   /* We couldn't identify the frame as an existing frame, but
    863      perhaps we can create one with a single argument.  */
    864   if (numargs == 1)
    865     return create_new_frame (addrs[0], 0);
    866   else if (numargs == 2)
    867     return create_new_frame (addrs[0], addrs[1]);
    868   else
    869     error (_("Too many args in frame specification"));

But this '0' address later creates a problem and asserts gdb : 

(top-gdb) info frame
Stack level 0, frame at 0x4004fc:
 rip = 0x0; saved rip 
dwarf2-frame.c:860: 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) y
dwarf2-frame.c:860: internal-error: dwarf2_frame_cache: Assertion `fde != NULL'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

This can be selectively reported as a message , rather than a assert later.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |naaaag at gmail dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=8864

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug backtrace/8864] selecting a frame by its address does not work

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-01-26 19:15 -------
Subject: Bug 8864

CVSROOT:	/cvs/src
Module name:	src
Changes by:	palves@sourceware.org	2009-01-26 19:15:25

Modified files:
	gdb            : ChangeLog 

Log message:
	Add forgotten PR tags:
	
	PR backtrace/9458, PR backtrace/8864

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.10141&r2=1.10142



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=8864

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug backtrace/8864] selecting a frame by its address does not work

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-01-26 19:18 -------
See here for a patch that addressed a part of the issue:

 http://sourceware.org/ml/gdb-patches/2009-01/msg00476.html

Some architectures will still internal error, though.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=8864

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.