This is the mail archive of the gdb-patches@sourceware.org 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: [PATCH] PR backtrace/9786


Nick Roberts wrote:
>     (gdb) target remote localhost:4444
>     Remote debugging using localhost:4444
>     0xb7fda810 in ?? () from /lib/ld-linux.so.2
>     (gdb) info frame
>     Stack level 0, frame at 0x0:

I'm guessing that i386 unwinder is noticing
that ebp is 0 and deciding this is the outermost frame.  The amd64
unwinder seems to handle this a bit different, and will probably end up
thinking that this is a frameless function.  i386-tdep.c has this:

i386_frame_cache ()
{
(...)
  get_frame_register (this_frame, I386_EBP_REGNUM, buf);
  cache->base = extract_unsigned_integer (buf, 4);
  if (cache->base == 0)
    return cache;
(...)


>      eip = 0xb7fda810; saved eip 
>     findvar.c:299: internal-error: value_of_register_lazy: Assertion `frame_id_p
>     (get_frame_id (frame))' failed.
>     A problem internal to GDB has been detected,
>     further debugging may prove unreliable.
>     Quit this debugging session? (y or n)

On Monday 23 February 2009 00:16:51, Joel Brobecker wrote:
> What do others think?

This internal error sounds suspiciously related to the fact that
there's no current way to distinguish a null/invalid frame id,
from an outermost frame id...  We should really fix that sometime.

-- 
Pedro Alves


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