Hi,

Encountered an endless loop with the debugger while stepping through code and the call stack window open. The Debug Output window is filling up with messages like this:

<-stack-select-frame 2158>
^done
(gdb)
<-data-evaluate-expression $fp>
^done,value="0x34bf780"
(gdb)
<-stack-select-frame 2159>
^done
(gdb)
<-data-evaluate-expression $fp>
^done,value="0x34bf780"
(gdb)
<-stack-select-frame 2160>
^done
(gdb)
<-data-evaluate-expression $fp>
^done,value="0x34bf780"
(gdb)
<-stack-select-frame 2161>
^done

Stopping the debugger is the only way out.

Windows XP sp2, gdb 7.3, Lazarus 0.9.31 svn 36383.

Not sure if I'll be able to reproduce this.

Ludo

It is reproducible. Let me know what I can do to get more info to debug his.

Ludo

I can see what happens, and where to build in protection.

It looks like it is searching for the parent frame of a nested procedure.

procedure Foo;
    procedure FooInner;
   begin
     // watches can refer to "Foo" (parent)
     FooInner;
   end;
begin   end;

If FooInner called itself 1000 times, then "Foo" is 1000 frames up

But in this case, it seems it was searching outside the stack. $fp is not changing. So gdb is not actually switching to that stack frame (likely because it does not exist)

----------
Does the app use threads?

It can also be, that if the app was compiled with optimization, the value that is searched for, was incorrect....

start lazarus with

--debug-log=c:\log.txt
--debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO

and send the logfile, please

try rev 36404

Problem fixed.

In case of a nested procedure you mentioned earlier, wouldn't the stack depth displayed in the Call Stack window be a reasonable ceiling for the stack walk? No need to walk back hundreds of frames if only ten or so levels are displayed.

Thanks a lot,

Ludo

What if you selected frame 10 as current and it is in a nested procedure? And as I explained, the desired frame could be many frames up....

A reasonable ceiling is the total count of frames in the stack. Which can be reported by gdb.
Indirectly that is used now, by detecting, if the fp now longer changes.

That saves issue the command to gdb. Every command sent, takes time, and there is already a huge amount of commands being sent.

Sometimes, it may have already been sent (the stack count command). So the value would be avail. But it was easier to fix the issue, the way I did. Because it doesnt need the the conditional, if the count is avail....

---------
The search for the parent procedure's frame often is just one, sometimes 2 or 3 frames. That is no problem.

But even without the issue you encountered, it might have to search a 100 frame (recursive calls of the nested proc). That will be slow. BUT
It will show you the value you want to inspect. And that is probably still faster than having to change the stackframe by hand all the time.