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]

Infinite backtrace on arm


Hi,

I backported arm kgdb to run in an embedded arm target running 2.2.16 kernel. 
I can debug the the target for the most part with gdb-5.3 over a serial 
connection. However, sometimes when I ask for a backtrace, the bt gets stuck 
recursing at the bottom of the bt. Here is an example:

Breakpoint 9, dimp_proc_bring_dsp_down (p_dsp=0x1022dc00, reason=7) at 
common/micro/dim/dimutl.c:247
(gdb) bt
#0  dimp_proc_bring_dsp_down (p_dsp=0x1022dc00, reason=7) at 
common/micro/dim/dimutl.c:247
#1  0x1005dff4 in dimp_bring_dsp_down (p_dsp=0x1022dc00, 
reason=DIM_DSP_ERR_OK) at common/micro/dim/dimutl.c:74
#2  0x1005ae20 in dimp_check_dsp_msgs () at common/micro/dim/dimdsp.c:1831
#3  0x100557a8 in dim_process_poll () at common/micro/dim/dimcomm.c:107
#4  0x10067d78 in dsp_timer1intHandler (irq=0, dev_id=0x0, regs=0x1018a820) at 
dspdriver.c:169
#5  0x1000c004 in do_IRQ (irq=1, regs=0x10ffdfa8) at irq.c:247
#6  0x1000b200 in linux_VECTOR_IRQ ()
#7  0x1000b200 in linux_VECTOR_IRQ ()
#8  0x1000b200 in linux_VECTOR_IRQ ()
[repeated ad infinitum...]

I found the following code check at blockframe.c:496 that is supposed to trap 
this situation:

  /* If ->frame and ->pc are unchanged, we are in the process of getting
     ourselves into an infinite backtrace.  Some architectures check this
     in FRAME_CHAIN or thereabouts, but it seems like there is no reason
     this can't be an architecture-independent check.  */
  if (next_frame != NULL)
    {
      if (prev->frame == next_frame->frame
        && prev->pc == next_frame->pc)
        {
          next_frame->prev = NULL;
          obstack_free (&frame_cache_obstack, prev);
          return NULL;
        }
    }

However, I found by debugging gdb that frame was changing by framesize. I 
think (but not confirmed) that this is happening because this is not caught 
by arm_frame_chain() and it is returning with:
    return fi->frame + fi->extra_info->framesize;

I fixed my problem with the following:
--- gdb/blockframe.c~   2003-10-26 00:17:13.000000000 -0400
+++ gdb/blockframe.c    2003-10-26 00:17:53.000000000 -0400
@@ -499,8 +499,7 @@
      this can't be an architecture-independent check.  */
   if (next_frame != NULL)
     {
-      if (prev->frame == next_frame->frame
-         && prev->pc == next_frame->pc)
+      if (prev->pc == next_frame->pc)
        {
          next_frame->prev = NULL;
          obstack_free (&frame_cache_obstack, prev);

I don't think this is the right thing to do, and that a fix is really needed 
in arm_frame_chain(). But I'm not sure what that might be. Does anyone have a 
suggestion?

Thanks,

Jon


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