Re: Feature Request (?): Debugger should stop on last line before an exception occured.
- From: "Skybuck Flying" <BloodyShame@xxxxxxxxxxx>
- Date: Fri, 19 Sep 2008 06:31:17 +0200
Outlook express works weird when replieing to you.
It changes the font in the reply.
After I started microsoft office 2007, and textpad and copied pasted the
text to check it, and went to outlook express options, and did nothing
else... then creating a new reply... the font is suddenly different... the
way I like it...
Maybe it's some weird kind of outlook express bug, maybe even office related
bug.
Anyway I checked your headers... you seem the be on a mac ?
First of all why are you on a mac ? :)
Second of all, are you replieing via html or some other weird encoding ?
It's weird.. anyway here is my reply to you:
"Rob Kennedy" <me3@xxxxxxxxxxx> wrote in message
news:6jgku2F38m47U1@xxxxxxxxxxxxxxxxxxxxx
Skybuck Flying wrote:
It would be more helpfull if the debugger would stop on the
last-successfully-executed-delphi-source-line before an exception
happened.
Now the debugger just goes to the exception handlers... which is mostly
mosterd/ketchup after the meal ;) :)
The debugger goes to the CPU window, if you let it.
Which would not be of much use since it would be on the exception handler
code...
Anyway.
The debugger could simply keep track of a variable: last good instruction
pointer...
Then when something bad happens.. for example it's on some exception
handler instruction pointer... it checks the last good instruction
pointer... searches which source line corresponds to that and simply
goes/"breakpoints" to that line or so.
I don't think the debugger can do this already ?
It doesn't. To do that would make your program run *very* slowly. In order
for the debugger to update the "last good line" variable, the debugger
needs to know which line has been executed. It can only know that if the
program tells it what it's about to execute. The program communicates with
the debugger through breakpoints. The debugger would need to put a
breakpoint on every source line so that when your program executes any
line, the debugger can update its variable before allowing your program to
continue.
You can notice similar slowdown if you set a conditional breakpoint (or
other advanced breakpoint) in a loop. Set the condition such that it would
break the loop on the last iteration. You should notice that the loop runs
much slower -- even for the iterations where it doesn't break -- than it
would run if the breakpoint weren't there at all. That's because on each
iteration, the debugger interrupts and evaluates the condition to see
whether it should really break.
Ok, I don't know how debuggers work... so this is kinda surprising to me...
but none the less...
A different debugger could be made which executes everything inside a
virtual environment ?
This would probably slow everything down even further... question is would
it be possible somehow ? :)
Maybe like something in between... all operating system code and dll's are
executed as normal.
Only the delphi application code and related stuff is executed in a virtual
debugger.
Suppose this is possible then the question becomes:
Would such a debugger be faster than the current debugger with breakpoints
set everywhere ?
Also this could open up other adventages:
The debugger could start counting the number of specify instructions to give
the programmer a better idea which instructions he is using the most.
This would also allow to profile the complete application which can also be
very usefull.
Like time used to execute routines, number of calls make etc.
It could be a debugger and profiler and instruction code analyzer all in one
!
"Rob Kennedy" <me3@xxxxxxxxxxx> wrote in message
news:6jgku2F38m47U1@xxxxxxxxxxxxxxxxxxxxx
Skybuck Flying wrote:
It would be more helpfull if the debugger would stop on the
last-successfully-executed-delphi-source-line before an exception
happened.
Now the debugger just goes to the exception handlers... which is mostly
mosterd/ketchup after the meal ;) :)
The debugger goes to the CPU window, if you let it.
Anyway.
The debugger could simply keep track of a variable: last good instruction
pointer...
Then when something bad happens.. for example it's on some exception
handler instruction pointer... it checks the last good instruction
pointer... searches which source line corresponds to that and simply
goes/"breakpoints" to that line or so.
So that's what this is a feature request (?) ;)
This would greatly help the programmer to quickly debug his/her computer
programs and immediatly find where something went wrong...
That's what the call stack is for.
I forgot about the call stack first of all.
And second of all... the call stack is probably limited to showing which
routines were called.
It doesn't show on which line inside a routine it crashed.
So it helps little.
I have to know at which line it crashed otherwise it's not very usefull for
access violations.
Especially for routines which have multiple pointers, and arrays.
Any of those could have caused it...
Bye,
Skybuck.
.
- Follow-Ups:
- Re: Feature Request (?): Debugger should stop on last line before an exception occured.
- From: Nicholas Sherlock
- Re: Feature Request (?): Debugger should stop on last line before an exception occured.
- References:
- Prev by Date: Comma after all parameters is accepted by compiler ?
- Next by Date: Re: Feature Request (?): Debugger should stop on last line before an exception occured.
- Previous by thread: Re: Feature Request (?): Debugger should stop on last line before an exception occured.
- Next by thread: Re: Feature Request (?): Debugger should stop on last line before an exception occured.
- Index(es):
Relevant Pages
|
