Revolution debugger issues
Dave Cragg
dcragg at lacscentre.co.uk
Thu Aug 4 04:13:29 CDT 2005
On 4 Aug 2005, at 05:07, J. Landman Gay wrote:
> I'm writing to the MC list because I don't want to start a flame
> fest on the main Rev list. Is anyone here using the Revolution
> debugger? There is a problem with it that has had me going around
> the bend for the last week and I'd like some help nailing it down
> so I can Bugzilla it.
>
> I sent Mark Waddingham a fairly complex stack that exhibits
> debugging problems constantly for me, but he couldn't reproduce
> them. I see that someone has entered a non-reproducible bug already
> about how the debugger exits prematurely when a url is loaded, but
> the team couldn't reproduct that either. It is similar to what I am
> seeing, but I believe it is a much broader problem than just
> loading urls.
>
> The basic problem is that while stepping through a script, the
> debugger will suddenly exit debugging mode completely. Breakpoints
> set after the point where the exit occurs do not break. Debugging
> becomes impossible because the error you are trying to find is
> somewhere after the point where the debugger stops working. The
> variable watcher contains no local values, only the usual globals.
For what it's worth, I never use the debugger (Rev's or MC's) when
working on libUrl. Unfortunately, I don't remember exactly why I gave
up on it. But I seem to have it fixed in my mind that the debugger
won't work when there are "out-of-synch" scripts running. (But I may
be confusing the debugger with try-catch statements which won't work
well in out-of-synch scripts). My theory (all conjecture) goes
something like this:
Say you have a handler like this:
on myHandler
## some stuff
load url someUrl
##other stuff
breakpoint
##more stuff
end myHandler
In this case, the load url command will cause liburl to perform a
number of "read from socket with message" commands. The lines
following the load url line in your handler will execute in the space
between the "read" statements in libUrl and the "messages" that get
fired when the reads complete.
Setting a breakpoint causes the current script to pause at the
breakpoint. What is less clear is what happens to other scripts that
may be running or waiting in the background. (read from socket with
message, pendingMessages, etc.) Are they halted too, or do they try
to run? And if they are halted, what are the consequences? For
example, I might expect a socketTimeout if a read was halted for a
long time, but would this be the case if the read completed, but the
firing of its associated message was held up. And if background
scripts do run at a breakpoint, do their variables somehow "bump-out"
the variables being shown in the variable watcher. Too much for a boy
like me to contemplate. So after seeing some odd behavior in the
debugger while working on libUrl (this goes back to MC 2.4.1) I gave
up on it. What I do now is similar to Scott Rossi's idea of tracking
expected values at various points in libUrl. I use liburl's own log
feature to trace these.
To check if this theory is valid at all, could you replace the "load
url" statements with "get url"? That would probably eliminate the
issue of out-of-synch scripts affecting the debugger.
Cheers
Dave
More information about the metacard
mailing list