This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: frame_register_unwind(): "frame != NULL" assertion failure


On Feb 17,  4:37pm, Andrew Cagney wrote:

> Anyway, Kevin,
> 
>    /* Use proc_desc calculated in frame_chain */
>    proc_desc =
>      get_next_frame (fci)
>      ? cached_proc_desc
>      : find_proc_desc (get_frame_pc (fci), get_next_frame (fci), 1);
> 
> can you please change the above to be:
> 
>      : find_proc_desc (get_frame_pc (fci), NULL, 1);
> 
> (with a comment) and modify read_next_frame_reg() to, when NULL, pull a 
> value from the register cache.

I have done this, but I am still seeing the assertion failure.  The reason
is slightly different, however.  Here's a partial backtrace:

outer-gdb> bt
#0  internal_error (file=0x84ae60 "/home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c", line=187, string=0x84aea0 "%s%sAssertion `%s' failed.") at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/utils.c:800
#1  0x005e4cf4 in frame_register_unwind (frame=0x0, regnum=31, optimizedp=0x7fff6dc8, lvalp=0x7fff6ddc, addrp=0x7fff6dd0, realnump=0x7fff6c80, bufferp=0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:187
During symbol reading, struct/union type gets multiply defined: struct elf_obj_tdata.
#2  0x005479cc in mips_get_saved_register (raw_buffer=0x7fff6db8 "\020\002\177\177m\020\002\177\177m", optimizedp=0x7fff6dc8, addrp=0x7fff6dd0, frame=0x100573c8, regnum=31, lvalp=0x7fff6ddc) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:5509
#3  0x00513dc4 in gdbarch_get_saved_register (gdbarch=0x10061790, raw_buffer=0x7fff6db8 "\020\002\177\177m\020\002\177\177m", optimized=0x7fff6dc8, addrp=0x7fff6dd0, frame=0x100573c8, regnum=31, lval=0x7fff6ddc) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/gdbarch.c:3931
#4  0x005e500c in frame_register (frame=0x100573c8, regnum=0, optimizedp=0x7fff6dc8, lvalp=0x7fff6ddc, addrp=0x7fff6dd0, realnump=0x7fff6dd8, bufferp=0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:212
#5  0x005e6eb0 in frame_saved_regs_register_unwind (frame=0x100573c8, cache=0x100573ec, regnum=31, optimizedp=0x7fff6dc8, lvalp=0x7fff6ddc, addrp=0x7fff6dd0, realnump=0x7fff6dd8, bufferp=0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:672
#6  0x005e4d60 in frame_register_unwind (frame=0x100573c8, regnum=31, optimizedp=0x7fff6dc8, lvalp=0x7fff6ddc, addrp=0x7fff6dd0, realnump=0x7fff6dd8, bufferp=0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:190
#7  0x0053687c in read_next_frame_reg (fi=0x100573c8, regno=31) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:1599
#8  0x00536ff4 in mips_frame_saved_pc (frame=0x100573c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:1722
#9  0x00518c3c in gdbarch_frame_saved_pc (gdbarch=0x10061790, fi=0x100573c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/gdbarch.c:4742
#10 0x0053a958 in mips_frame_chain (frame=0x100573c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:2434
#11 0x00518710 in gdbarch_frame_chain (gdbarch=0x10061790, frame=0x100573c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/gdbarch.c:4690
#12 0x005e7fd0 in legacy_get_prev_frame (next_frame=0x100573c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:1012
#13 0x005e87a0 in get_prev_frame (next_frame=0x100573c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:1253
#14 0x004f61f8 in backtrace_command_1 (count_exp=0x0, show_locals=0, from_tty=1) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/stack.c:975

If I were to follow your above suggestion, I would also have to add some
explicit regcache fetching code to mips_get_saved_register() too, but I
really can't believe that this is the best approach.

To cleanly solve this problem, I believe that get_next_frame needs to
be able to return the sentinel frame.  But in order to do so, current
usages of get_next_frame() need to be fixed to not check for NULL.

The other approach, less clean, but certainly expeditious, is to use a
hack similar to the one that I've already posted for
frame_register_unwind().

Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]