BREAK Command Features

General development discussion.

Moderators: Susan Smith, admin, Gabriel

Post Reply
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

BREAK Command Features

Post by gordon »

A few items I have not been aware of that ease debugging are:
  • * The BREAK command can name a user defined function instead of a label or line number. This will cause the program to enter step mode when the function is entered.
    * Break line references can refer to clause numbers as well. e.g. BREAK label-name:clause-number.
    * Conditional breakpoints can be placed anywhere in a program as follows:

    Code: Select all

    00500 if A > B then execute"GO STEP"
    This will cause the program to enter step mode when the condition is met.
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: BREAK Command Features

Post by Gabriel »

This is pretty neat.

I did not realize number 1) (that break can name a user defined function, or a label for that matter). I didn't realize they could handle Clause numbers.

Conditional breakpoints are cool, but they're kind of elementary .. I mean most of us have been doing the same thing but with "PAUSE" instead of Execute "GO STEP" for this purpose.

Now, other useful functionality that people might not be aware of:

BREAK MyVariable

will cause BR to enter Step Mode any time MyVariable changes.


Gordon: Is there any change we'll get that same functionality for System Functions? It would really be useful to be able to say BREAK File(45), and have BR enter Step Mode whenever the status of File 45 changes.

For example, I occasionally have to track down a bug where some code is inadvertently closing a file handle and I need to track down which code is doing it, (out of 15 libraries of nestled functions). This would really help.

If you're putting that functionality in there anyway, and it wouldn't be too hard to do, it would also be nice to be able to evaluate variables in the execution of system functions for this purpose. For example, can we have:

BREAK file(CustomerFile)

work, so that any time the status of the file number contained in the variable "CustomerFile" changes, then it pauses? And if CustomerFile changes in the middle of the debugging, then it pauses on status changes of whatever file channel CustomerFile now points to?
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Re: BREAK Command Features

Post by gordon »

Gabriel.. I'm sure you realize that some of your challenges are not experienced by the majority of BR users. Most of us do not have to deal with someone else's spaghetti code. On the other hand I have a feature in mind that would solve your problem, along with many others.

I didn't want to pre-announce anything because it is not done yet, but I have the following feature on the development list for BR 4.4:

BREAK IF FNmyUserFunction

FNmyUserFunction would be executed before every statement and if it returned a nonzero value the program would drop into step mode.

This would slow down processing significantly but depending on the definition of FNmyUserFunction it would not be prohibitive.

Only one such statement could be active associated with each program.
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Re: BREAK Command Features

Post by GomezL »

I think the user-defined function will be fantastic!

I also give my +1 to file handle changes.

As libraries start to call libraries, and sometimes those libraries are other peoples code (like screenio), I am finding that file handles that were set by the "Main Program" are being replaced by other programs.

The story goes something like this

Main Program
* OPEN - FNGETHANDLE [FILE1] (Assigns 999)
* CALL FNLIBRARY
** Tries to be a good citizen, and closes all open files #1 - #999
* Call FNOther Function
** Uses OPEN - FNGETHANDLE [FILE2] (Assigns 999)
* Main Program tries to use FILE1 (999) which has now become FILE2 (Because of FNOther)

If I could set a breakpoint when the file opens/closes, it would be trivial to debug.
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: BREAK Command Features

Post by Gabriel »

BREAK IF FNmyUserFunction

FNmyUserFunction would be executed before every statement and if it returned a nonzero value the program would drop into step mode.
Gordon, if fnMyUserFunction can be any statement that returns zero/nonzero, and not just a custom function, then that would provide the best of both worlds. It would give us the ability to debug many things without writing a custom function for it, and other more complicated things could be debugged with a custom function, when needed.

Its generally good if you don't need to change your running program too much like adding extra debugging-only functions, unless its necessary.

However, that still doesn't' easily give us the ability to tell when the results of a system function change. It would be really useful to lots of people to be able to pause on results of the file() function.

It may only be the file() function that is needed, actually -- i'm not sure. Thats the only one I've wished i could use.


Yes, I do see how you could do this with a custom function, but thats a bit complicated for a one time debugging tool that you might use only once in a year. Remember too, that, in this situation, the file might be changed by any of a number of different nested library functions in different code spaces. Would the function have to be defined in all of them? or how would that even work?


** Tries to be a good citizen, and closes all open files #1 - #999
Luis, I'm not sure a good function should ever close all open files .. that seems like it would cause problems.

However, I see your larger point - I can think of lots of reasons that breaking on the change of a file number would be really helpful.

Gabriel
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Re: BREAK Command Features

Post by GomezL »

I am sure that a good function should never close all open files!
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Re: BREAK Command Features

Post by gordon »

The idea in calling a custom function is to allow one program snippet to check for any number of conditions. Defining a debug function would not affect normal processing because normally the BREAK IF command would not be issued.

I thought about issuing a temporary, immediate statement that would be only in memory, but it would be too limiting. Ideally this needs to support multiline debug functions.

A function naturally returns a value. It could check the File$() value of one or more files to see if it changed from the first such test.

==========================================================
With respect to BREAK commands applying to multiple programs..
If -p (program) is stated in a BREAK or DISPLAY command, BR tries to match the string after -p to the currently loaded program. If it can match the current program path and name then the full path to the current program is stored as the -p value. Otherwise it stores the -p value unmodified and it is checked for each program run.

Therefore if you CLEAR any presently loaded programs and issue a BREAK or DISPLAY command with -p BR it will apply to all programs subsequently run.

example:
CLEAR
DISPLAY -P BR ALL

This will display all variables changed in all programs run.

Given that information one could create a debug library to be referenced by the following snippet:
DEF FNDEBUG
IF NOT DEBUG_LIBRARY_CALLED THEN
LIBRARY "DBGLIB": FNDEBUG1
DEBUG_LIBRARY_CALLED = 1
END IF
FNDEBUG = FNDEBUG1
FNEND

The following commands would process FNDEBUG1 ( located in DBGLIB ) in every program that contained this snippet:
CLEAR
BREAK -p BR IF FNDEBUG

Keep in mind, the FNDEBUG linkage would have no effect when the BREAK command was not in use.
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

Re: BREAK Command Features

Post by John »

I also give my +1 to file handle changes. When working with my own code base which is 30+ years old now, which some of it has hard coded file numbers and some of it uses functions to return available file handles - sometimes there are conflicts that were unforeseen when I updated part a program or a function. Sometimes those issues aren't seen for months and you have no idea where that file handle is getting closed on you. It can be difficult to walk through all the functions a program calls and wait for it to close the wrong file.
John Bowman
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: BREAK Command Features

Post by Gabriel »

gordon wrote: example:
CLEAR
DISPLAY -P BR ALL

This will display all variables changed in all programs run.

Given that information one could create a debug library to be referenced by the following snippet:
DEF FNDEBUG
IF NOT DEBUG_LIBRARY_CALLED THEN
LIBRARY "DBGLIB": FNDEBUG1
DEBUG_LIBRARY_CALLED = 1
END IF
FNDEBUG = FNDEBUG1
FNEND

The following commands would process FNDEBUG1 ( located in DBGLIB ) in every program that contained this snippet:
CLEAR
BREAK -p BR IF FNDEBUG

Keep in mind, the FNDEBUG linkage would have no effect when the BREAK command was not in use.
The more you describe this the more complicated it sounds, when all we want to do is know which line of code is closing our files.

You're saying i'll need to write a debug library, then add a patch of code to every program in my entire system that calls this debug library when all I want to do is one time, like, one time ever, say "BREAK FILE(4)".

Such a debug library would eventually come to handle all manner of things -- but then why not just include that in BR instead of making us put a piece of code in every program in our system just to debug things?


All we need is to know which function closed our file. Can't you give us that ability much more simply without us having to wait until 4.4 and write a bunch of kludgy code that has to be placed in every one of our programs?
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Re: BREAK Command Features

Post by gordon »

It sounds like BREAK FILE nnn would be used quite a bit.

Good suggestion. I'll put it on the 4.4 list.

4.3 is in "bug fix only" status.
Post Reply