Debugging tools

[Mick Berg]

Are there any instructions anywhere on how to use the debugging tools? I don't find them very helpful and I'm sure it's because I don't know how to use them properly.
Thanks,
Mick Berg.

[kevin]

   What are you expecting a debugger to do ?

    The debugger is for monitoring the logic/state of a program while it executes.    I'd most commonly use the variable/array viewer / console and media state.    But  if i'm really stuck, i'd trace the logic through line by line.   Unfortunately that can be a little clumsy (today) due to the page flipping required (between program & variable tabs).  But anyway, that's not the point.   

    If you run a program in full debug/race mode.  (F6)  During compile the the compiler laces the code the debugger feedback operations.    So this lets you stop the program the real time and step through it.    You can step forward  (single arrow) or trace forward.   When you STEP the debugger will follow your code through function calls/ everything.    When you trace (double) arrow it will only show show the next operation in the current scope.  So if you halt/break while executing a function, you and trace forward and it will only stop again when the function is called next.   This allows you view the behavior of specific section of code, ignoring the rest.

   You can fine tune via using the #BREAK and #TRACE directives.    #BREAK directive forces the compiler to insert a STOP opcode.  Whenever the runtime hits this ocode it halts execution and refreshes the debugger (when in debug mode).   This can useful when you want the app to stop at key points.    An example of which might be at the start/end of the function so you can see the exact state of not just the current scope, but every scope.

    #TRACE on the other, lets us tell the compiler when it's allowed to embed trace operations (it's monitoring opcodes) into our program.  So we can tag ranges throughout a program that will or will not have debugger hooks in them.   This has an added benefit of speeding up the execution of those areas where tracing has been disabled from (when compiled / running in F6 mode)    But it's mainly useful when we want focus on the debugging a particular area of the code, and not just a function.   

    #Print is for dumping stuff to the console tab in the debugger.  Since print is a directive #print has the added bonus of being ignored (totally removed from compilation) in anything other than a debug mode (F6/F7).   This can used to dump data/messages to.   The latter is useful for finding logical issues also.  Like you stop your program, then look through the console output to double check the program is following the logic you've step up.     

    In more recent additions of the PB 1.61 (and above) you can view the arrays & types contents from the variable viewer.  This lets you view into the structure and double check it's contents.   

    The state view is more about monitoring your programs overall behavior for 'memory leeks'   That is programs that allocate resources (create something), then don't delete them prior to allocating more resources.   Which is logical problem in the program, that may not be readily noticeable. 

   There's also a  lesser known  PBDebug Slib (look in Slibs folder people !).   The library is a sort of crude image viewer than be built into your program.   It lets you Pop up the viewer and browse the images (CTRL D)   while your app runs.  Again, useful more double checking just what images are what !

Code Select Expand



#include "PBDebug"

SetFps 30

Cls 255
GetImage 100,10,10,64,64

Do
Cls 0

MyFunction(a,b,c)

DrawImage 100,50,50,true

DebugImages()

Sync
Loop



Function MyFunction(a,b,c)
inc a
inc b
inc c

EndFunction


[Mick Berg]

Thanks for that Kevin. Sorry I only saw your reply today.
Mick.