On 29/03/2012 08:35, Ludo Brands wrote:
It is reproducible. Let me know what I can do to get more info to
debug his.
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.
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.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
