[Octave-bug-tracker] [bug #47605] dbwhere hangs after debug_on_error stops Octave

[Rik]

Update of bug #47605 (project octave):

                  Status:               Confirmed => Patch Submitted        

    _______________________________________________________

Follow-up Comment #7:

I spent a little time with the debugger.  The backtrace is


#4  0x00007ffff5a18a8a in octave_call_stack::do_debug_user_code
(this=0x608000041fa0)
    at libinterp/corefcn/toplev.cc:320
#5  0x00007ffff554b497 in octave_call_stack::debug_user_code ()
    at libinterp/corefcn/toplev.h:230
#6  0x00007ffff553d6d8 in get_user_code (fname=...) at
libinterp/corefcn/debug.cc:183
#7  0x00007ffff554776d in Fdbwhere () at libinterp/corefcn/debug.cc:1506


The important code in toplev.cc is:


  // Start looking with the caller of the calling debug function.
  size_t i = cs[curr_frame].m_prev;

  while (i != 0)
    {
      const stack_frame& elt = cs[i];

      octave_function *f = elt.m_fcn;

      if (f && f->is_user_code ())
        {
          retval = dynamic_cast<octave_user_code *> (f);
          break;
        }
    }


As you can see, it is a while loop but nothing changes the value of the index
variable i.  The attached patch fixes up three instances of this in toplev.cc.
 It should be reviewed by jwe since I'm only guessing about the code's intent.
 On the other hand, the patch does work for me.
It is only my intuition, but I suspect the stack context is maybe
uninitialized (NULL) when the debugger is triggered through an error or
warning condition.  


(file #36835)
    _______________________________________________________

Additional Item Attachment:

File name: dbwhere.diff                   Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47605>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/