Board Logo
« Tips on using the Debugger »

Welcome Guest. Please Login or Register.
Jan 18th, 2018, 3:51pm


Conforums Terms of Service | Membership Rules | Home | Search | Recent Posts | Notification | Format Your Message | Installation FAQ

This board is not meant for general discussion, it is meant for posting articles to help others.
For general discussions use the appropriate board, which best describes your problem area.

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Tips on using the Debugger  (Read 3888 times)
AltBas
Full Member
ImageImageImageImage


member is offline

Avatar




PM


Posts: 461
xx Tips on using the Debugger
« Thread started on: Mar 20th, 2012, 2:03pm »

The Just BASIC help file has a nice basic introduction to the debugger, so I won't go over that. My intent is to give handy tips about debugging. If you can't access the help files that came with JustBasic, html help files are on the JB wiki.

The blue right-pointing triangle "Run" button is not the debugger. It merely runs your code, and tells you the reason why it stopped if there is an error.

The red "ladybug" or "ladybird" button starts the debugger. You can run your code with the blue right-pointing triangle "run" button, and if there is an error, it stops on the line of code, and displays the error message in the status line at the bottom of the debugger window. (Be sure you can see this line, you may need to raise the window a bit if you don't allow the taskbar to minimize.) This still isn't debugging, it is just running your code until it crashes, or successfully completes (ie, Just BASIC found nothing wrong with the code, though results may be totally incorrect). If you have pressed the blue "Run" button inside the debugger, and your code is taking too long to complete, you can click the "Stop" button (the two vertical bars next to the "Run" button) to stop the code execution at some random place, then start single stepping your code to see what the slow down is caused by.

Debugging is the tedious process of stepping through your code, watching the variables change value as lines of code execute. The best point of the debugger isn't mentioned in the help file however. The JB debugger has one breakpoint. A breakpoint is feature that lets the code execute until it reaches the breakpoint, where it stops (breaks), and displays the current variable values. The breakpoint is not available as a button, you must click on the line of code where you want it set, and either select the menu Code / Run to Line with the mouse, or on the keyboard press Alt; C[ode]; L[ine]. This lets your code skip over many lines of code to the point where it is not working right (if you have set the breakpoint there).

You can use the breakpoint technique to see if a section of code is being used.

*****
Tip: Put "guard" statements around the breakpoint in a loop.

Say you have a loop that runs 10,000 times, and you aren't getting the values you expect out of the loop. Put a block IF..THEN statement inside the loop. Put the breakpoint on the statement inside the "guard" statement, or else it breaks every loop, and you will have to re-start the breakpoint with the mouse/menu combination.
Code:
for i = 0 to 10000
  if (i MOD 1000) = 998 then  '* "Guard" statement *
    dbg = 1                   '* Line to place the breakpoint on *
  end if
  '* Or - *
  if CriticalVar >= CriticalValue then  '* "Guard" statement *
    '* Or "CriticalVar >= CriticalValue - CriticalStep", etc. *
    dbg = 1                   '* Line to place the breakpoint on *
  end if
next i
 

The first debugging condition stops the FOR..NEXT loop several times so you can watch the variables. You want to stop the debugger a loop or two before the problem is thought to occur so you can watch the variables as you single step through the code. It's too late if the debugger stops after the error calculation occurs. Or you can make the bad calculation result the test in the IF..THEN statement so you can see the variable values that caused the bad result. If you are searching for the cause of an array overflow, you definitely want to stop early.

The second debugging condition targets the critical value of some variable. Perhaps you are searching for why there is a divsion by zero, or why the code is trying to perform x = LOG(0). Using the Run button in the debugger can show you which variable to watch, or which series of variables.

Hint: Mark these debugging statements with a special comment tag so you can find and remove them later. The variable which has the breakpoint set on it in the debugging statement should not have any use in the program. I generally use a variable named "dbg" as shown above.

*****
Tip: The debugger won't stop on a breakpoint immediately following an event
handler label.

Code:
[AddEntry]           '* <- Event handler label *
  Entry = Entry + 1  '* Breakpoint won't break if set here *
  select case Entry  '* But it will if set on this line *
    '...
  end select
  wait
 


Note: A breakpoint on a label (goto or gosub) won't break.
Note: A breakpoint on an empty line won't break.

*****
Tip: Some statements are better than others for breakpoints.
Code:
if a = b then
  a = b + 1
else
  b = a + 1
end if
 

In the above code snippet, a break point on the "a = b" line always breaks, a breakpoint on the "else" line breaks after the "a = b + 1" block executes, and a breakpoint on the "end if" line always breaks.

Code:
select case a
  case 2
    print a
  case 1
    print b
  case 0
    print a; b
  case else
    a = a - b
end select
 

In the above code snippet, a break point on the "case 2" line always breaks, and a breakpoint on the "case 1" line always breaks, because the "case" statement following an executed case statement block always breaks, but then code execution jumps to the "end select" statement. A breakpoint on "case 0" breaks if the "case 1" block executes, but not if the "case 2" statement executed. And so on down the select statements. The "end select" statement always executes. To have a breakpoint within a case, you have to set the breakpoint on a line of code within the case, eg on "case 2" you would set the breakpoint on the print statement. Due to the design of the select statement, the end select statement may execute many times, depending how many case statements were tested.

*****
It is a sad fact of life that on a large programming project, you are going to spend more than 50% of your time debugging why your program doesn't work correctly. So don't write too much code before you start debugging. Then focus on one part of your code at a time. Be sure the code for "Button 1" works before starting on "Button 2". If debugging "Button 2" code changes code also used by "Button 1", go back and re-test "Button 1". Being methodical may not be exciting, but it can cut down on the amount of time you spend debugging.

Test many different conditions. If you are reading from a data file, be sure it can handle (unexpected) blank lines, missing data fields on a line, wildly incorrect data values (eg, garbled data lines), non-data files. Especially if you expect other people to use your program with happiness.

Happy debugging...

- AltBas
« Last Edit: Dec 30th, 2012, 11:53am by AltBas » User IP Logged

NJames
Senior Member
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 661
xx Re: Tips on using the Debugger
« Reply #1 on: Mar 20th, 2012, 9:29pm »

shocked I can set a breakpoint? shocked
I was doing this with input statements! embarassed

Thanks AltBas!
User IP Logged

AltBas
Full Member
ImageImageImageImage


member is offline

Avatar




PM


Posts: 461
xx Re: Tips on using the Debugger
« Reply #2 on: Mar 20th, 2012, 10:43pm »

Hey, that's a valid method also, since there is only 1 breakpoint available, very limiting. I never thought of that - thank you in return.

- AltBas
User IP Logged

tsh73
JB-Supporter


member is offline

Avatar




PM

Gender: Male
Posts: 3636
xx Re: Tips on using the Debugger
« Reply #3 on: Mar 21st, 2012, 01:38am »

Really nice set of tips.
As for "The debugger won't stop on a breakpoint immediately following an event handler label.", that probably should be reported as a bug.
EDIT
Interesting but this bug is not present in current LB4.04.
« Last Edit: Mar 21st, 2012, 02:15am by tsh73 » User IP Logged

Q: "And if I took your codes and compile them, and sell them for a profit"?
A: Go ahead. I had my share of good then I coded it for fun, if you can make better use of it - please do.
(enjoying JB 1.01 on WinXP, netbook and desktop)
Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Conforums Terms of Service | Membership Rules | Home | Search | Recent Posts | Notification | Format Your Message | Installation FAQ

Donate $6.99 for 50,000 Ad-Free Pageviews!

| |

This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls