Setting a conditional breakpoint 101

Setting a conditional breakpoint 101

Hello all.  At long last, I have found it necessary to use one of ComposerXE's features that's supposed to let you set a breakpoint and run until some variable reaches a set value.  In this case, the variable is an integer.  Ideally, I'd like to run to a breakpoint until a variable in that scoping unit reaches some value, and then pause, allowing me to take over and then run debug on my own (e.g., using F5s or F10s to step through the code).  Is this a tall order?

Unfortunately, I don't see anything relating to "conditional breakpoints" in the Debug dropdown menu, and after searching this forum I don' really see any basic discussion on this functionality.

FWIW, I'm using VS2010 and have XE 2013.

Any suggestions?

24 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Sometimes, the problem is the mapping between the debugger's GUI and the underlying capabilities of the debugging engine. I have used two types of data breakpoints. If you know the address of the variable (you may have to find this from a variables list), you can set a breakpoint on read and/or write access to that address. This type of breakpoint uses the hardware debug support in the CPU.

The second type of breakpoint may require that you localize the breakpoint to a few lines of code that you are sure will be executed, within which you want the break to occur only if a condition is satisfied. To set this breakpoint, the GUI may require that (i) you set an unconditional breakpoint at one or more lines of code, and then (ii) modify the breakpoint by adding conditions.

  1. Set the breakpoint on the line you want to break at by clicking in the leftmost column.
  2. Right click on the red breakpoint dot and select Condition...
  3. In the Condition field, type the expression, in Fortran syntax, you want to be true (or have changed) when the condition is to be met. If you want it as changed, select that radio button. Click OK
     
Steve - Intel Developer Support

Quote:

TommyCee wrote:

Hello all.  At long last, I have found it necessary to use one of ComposerXE's features that's supposed to let you set a breakpoint and run until some variable reaches a set value.  In this case, the variable is an integer.  Ideally, I'd like to run to a breakpoint until a variable in that scoping unit reaches some value, and then pause, allowing me to take over and then run debug on my own (e.g., using F5s or F10s to step through the code).  Is this a tall order?

Unfortunately, I don't see anything relating to "conditional breakpoints" in the Debug dropdown menu, and after searching this forum I don' really see any basic discussion on this functionality.

FWIW, I'm using VS2010 and have XE 2013.

Any suggestions?

There are several ways to do this in Visual Studio, but I agree with you - these things are not documented as well as they can be and unless one is very familiar with integrated development environments (IDE) in general, none of it is exactly intuitive.  But once you figure out how to do it (it can initially be a hard-slog!), it may all appear trivially simple in hindsight!

I just had to debug something a couple of hours ago similar to what you're trying to do and here's how I went about it:

  • Note I usually have the breakpoints window visible in Visual Studio.  You can too by either Ctrl+D,B or by going to Debug on the VS menu bar -> Windows -> Breakpoints
  • set a breakpoint at the relevant line in the code
  • right-click on the breakpoint in the Breakpoints window
  • Select "Condition" from the pop-up that comes up when you right-click
  • Add a Fortran expression e.g., (I == n) where I represents the integer variable of interest to you and n is some valid integer value (1, 2,..50, etc.)
  • Set the Radio button to "Is true" in the "Breakpoint Condition" pop-up
  • Now run the debugger and it should stop when the expression you typed in becomes true.

You can look in Visual Studio Help documentation, Microsoft's MSDN site, and gazillions of other websites for information on how to use the debugger in Visual Studio and many features therein including various aspects of conditional breakpoints, etc.  All that you learn in those places generally applies to Fortran code as well.

What you get with Intel Fortran's integration with Visual Studio is facility with Fortran syntax in the debugger e.g., condition statements, Watch variables, etc.  But the concepts are general and they apply to all programming languages that are supported by Visual Studio.

 

Thank you Steve & FortranFran for very clear instructions on how to set up a condition breakpoint.  I followed your simple instructions and set the compiler in motion.  My routine reads & processes hourly records from a flat ASCII file and I tried to have it stop at RecNum = 7520.  It fairly quickly ran to the breakpoint and, looking at RecNum in my Watch window, I see that indeed is displayed a value of 7520.  However, none of the variable values associated w/ this record were displayed.  After checking, I discovered that it really stopped w/ the very 1st record.  In other words, while indicating that it had skipped down to the 7520th record, it actually stopped at the 1st record.

Does this make any sense to anyone?

TommyCee,

There must be some other things that are in effect which somehow interfere with your conditional breakpoint.

It appears you are in a READ loop that is supposed to execute more than 7520 times.  All I can suggest: a) make sure you are running an up-to-date version of the entire code in the debugger (can you do Rebuild All for your Debug configuration), b) make sure no other breakpoints can interfere with the one of immediate interest, and c) step through the READ loop a few times first i.e., have it finish reading RecNum=1, 2, 3, etc. and check whether it is reading each of these records ok.  Now bring the conditional breakpoint into effect and let it rip.  See what happens then.

Yes, you're right, FortranFan.  The input file has one year's worth of hourly records (8760).   I tried your advice.  Firstly I did Rebuild All (and there is only one breakpoint).  Then I stepped through the first 6 records (all results were as expected), then set the conditional BP at RecNum = 7520 and "let her rip".  It appeared to run  to the right spot in the sense that the value displayed for RecNum in my watch window is '7520'.  But it's fooling w/ my head.  The record it just read was actually the very next one (i.e., RecNum = 7).  I know this from the values of several other variables associated w/ this record.

....and then what do you observe if you manually step on a record?

It might also help if you post a code snipped of the read loop. These types of problems always have a logical explanation.

 

Quote:

TommyCee wrote:

.. then set the conditional BP at RecNum = 7520 and "let her rip".  It appeared to run  to the right spot in the sense that the value displayed for RecNum in my watch window is '7520'.  But it's fooling w/ my head.  The record it just read was actually the very next one (i.e., RecNum = 7).  I know this from the values of several other variables associated w/ this record.

TommyCee,

Do you specify "RecNum = 7520" or "RecNum == 7520" as the condition for the breakpoint?  Note it has to be the latter.  Can you confirm?  You may have realized the conditional breakpoints have an analogy with IF statements in Fortran that operate on LOGICAL variables.  Hence the condition you set in the breakpoint would be analogous to how you would write IF (RecNum == 7520) THEN do something.

Well duh!?!

Right on, FortranFan.  That was the deal breaker.  Unfortunately, along w/ other guidance sorely lacking for the cond. BP, the syntax, too, was not really specified.

At last, the debugger stops where I specified, and I'm in Fortran Nirvana!

I gotta tell ya - over the past few months - like a moron - I've spent a lot of time tapping on F5 to step thru my code (recently, 3080 times!).  All the while I would periodically glance over my shoulder to be sure no guys wearing white coats were standing there watching me. ☺

Thank you so much for the help - made my day.

Glad it worked out.  For anything to do with Visual Studio, I first try to figure how to do something with C, C++, etc. (and for which there is tons and tons of help in cyberspace) and then extend the concept to Intel Fortran, usually successfully.

OK, FortranFan, I now wonder if we might take this one step farther.

Suppose you wish to do a "joint condition", e.g.,

RecNum = 7520 and Var2 > x

or perhaps

RecNum = 7520 or Var2 = y

Is this a tall order?  If this is a doable, what would be the syntax within the condition field?

RecNum == 7520 .and. Var2 > 7

RecNum == 7520 .or. Var2 = 45

 

 

 

You can set conditions such as "RecNum == 7520 .and. Var2 > 7" on a breakpoint, but keep in mind that there can be a huge slowdown if you place the condition on a line of code that is executed many times.

With such conditional breakpoints, especially more than one or with a complex condition, your program may run as slowly as a program written in an interpreted language.

Thanks for your reply & confirmation, mecej4.  I take your point about the speed influence - I get that.  I was mainly trying to establish that specifying a joint condition is doable, and what might be the proper syntax to set it up.

It appears that one would use the usual F90 syntax, without the parentheses bounding the expression.

This site at Microsoft's Developer Network (MSDN) gives good background on breakpoints that is generally valid for Fortran too.

FWIW: at times. for complex stop/pause criterion during debugging, I've added temporary IF blocks or SELECT CASE constructs in the code and placed breakpoints within them.  

FortranFan,

Thanks for the link.

It would be nice if a conditional break point could also be set on memory change too. Pseudo operation:

BreakIf( ifChanged(varA) && (varA == 123) && (otherVar > 456))

IOW when you know the state when an error occurs but not the location that setup the condition.
Of course, the memory locations would have to be static (in module or SAVE) or at least persistent (in an allocated objects).

This is a MS VS issue not Intel. However, Intel would have heavier weight in offering this suggestion if they too find it useful.

Jim Dempsey

www.quickthreadprogramming.com

Good points, the last two.  (Hi Jim - you know me in the "SACTI circle").

The conditional break point feature in IVF is certainly one of its most powerful - that can't be overstated.  It's huge!

Given all that has been said on this topic, especially the lack of easy-to-get-to guidance for using the proper syntax, etc, I humbly suggest that the IVF developers (Hint Steve L.) enhance the Breakpoint Condition dialog with an info pop-up or something to convey basic syntax parameters so that the uninitiated (like me) would get a quick clue as to how to set up an even basic breakpoint trap.

I'd be glad to graphically design what this might look like (could do a mock-up in PowerPoint) but unfortunately the only images one can post to this thread must be accessible via a URL (at least the way I understand the process)

In any case, I make the point and the how-to-do-it I defer to the bright IVF developers.

Unfortunately, that dialog is part of Microsoft code we can't touch. Our code gets called only to evaluate the expression you specify.

VS does have "break on data change".

Steve - Intel Developer Support

At some point in the past (1990's) I seem to recall the Borland IDE permitted the conditional breakpoint expression to contain a function call to a function you write with your application. This would permit you to construct qualifiers of any complexity.

Jim Dempsey

www.quickthreadprogramming.com

Steve,

Considering the general theme of this thread on improved help on the use of breakpoints in Visual Studio, will it be possible to request Intel Fortran Help writers to add a section in "User and Reference Guide for the Intel® Fortran Compiler" on debugging in general but with details on key aspects such as breakpoints?  I did a quick check in my version (XE 2013 base release) but didn't find anything.  It may help if such a section were present in, say, User and Reference Guide for the Intel® Fortran Compiler -> Getting Started -> Using Microsoft* Visual Studio* (Windows* OS).

Thanks,

 

You mean like this?

Steve - Intel Developer Support

Not bad, Steve, except the section Adding Conditions to File Breakpoints needs to be rewritten.  I'd be glad to do it, and send you a strawman.  How it should be rewritten, and what needs to be added, is clear from this thread.  As it is, it leaves too much to the imagination.

Sure, send me your suggestions and I'll pass them on.

Steve - Intel Developer Support

Quote:

Steve Lionel (Intel) wrote:

You mean like this?

Thanks Steve.  I was looking in the wrong place:

  • It might be helpful to have a link in the Getting Started -> Using Microsoft* Visual Studio* (Windows* OS) section to Compilation -> Debugging since it is not exactly easy to search within Help.  I wish one could restrict one's search and navigation to specific content, but that's a separate discussion.
  • Also, as TommyCee pointed, the existing information on breakpoints appears thin on content and it leaves out the most critical information i.e., the syntax of breakpoint conditions.  So whatever your writers can do to improve content (using input from users such as TommyCee) will be valuable indeed. 

Leave a Comment

Please sign in to add a comment. Not a member? Join today