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