Debugger steps one line backward

Very much miss this feature of the debugger when it tells what source line was previous to the current one ('go back one line').

In the case of the large tricky source codes where multiple jumps occur often the program may go to the end stop and you do not know which condition caused this. With the feature when debugger tracks line-to-like transitions finding that would be in a snap and not a week like with my current program

Dan

As I understand it, the only way to do that would be to set a break at the previous line and then restart the application. Then you would need to know how many times that line had been visited since the start and count up accordingly.

I think that what Dan is asking for is a line-number traceback similar to a stack traceback. The debugger could keep a ring buffer of, say, the line numbers of the last five statements executed, and display these line numbers in a line-number pane. That capability would help with code such as

IF(cond1)goto 100 ... IF(.not.cond2)goto 100 ... 100 print *,'Error exit being taken' return

Without that capability, one has to keep an indicator that identifies which condition caused the jump to 100 to be taken:

ierr = 0 if(cond1)then ierr = 1 goto 100 endif ... if(cond2)then ierr = 2 goto 100 endif ... 100 print *,'Error exit number ',ierr return

Dan, there is a partial solution already available : use the /RU compiler option; it is supported only in 32-bit EXEs. There is another option /RO, which, according to the help information, only traces routine entries, but it does not seem to do anything in 32-bit or 64-bit mode.

Paul, mecej4, Yes, mecej4 correctly described what I meant. In the route of improvement of the debugger this could be one of the greatest features.

Tried /RU for one minute on simple code without reading any documentation on how it works. Yes, it could be usable too if error happen quickly after start, not few hours later because permanent Printing will slow execution by many orders of magnitude

The /RU output goes to the console. At present, it is not managed by the debugger, so you will need to position the command window and the SDBG window side-by-side so that you can see both.

The FTN95 option /ROUTINE_TRACE looks like it was added for some (forgotten) special need. It actually provides calls to SYSTEM_INFO@ which in turn creates a trace file called C:\system_info. So you will need to run 'as administrator' from a command line and pick up this file from the root C drive.

I am not sure if this option serves any ongoing useful purpose. If it does then we should change from writing to the C drive to somewhere more accessible.

At first sight both this and /RUNTRACE could easily be ported to 64 bits.

Thanks for the tip regarding the name and location of the trace file produced when /RO is used at compile time. I had expected to see the output go to the console, just as with /RU.

On Windows 10, the actual location is %LOCALAPPDATA%\virtualstore, rather than the root directory of the system drive.

During the next few days I hope to see if/how I can use these facilities for debugging. It appears that the trace produced by /RO records only the first entry to a subprogram, so it cannot be used to study chained subroutine calls or count the number of times a subprogram was called. The FTN95 help file does not mention /RO at all. Typing FTN95 /? shows this:

/ROutine_trace Adds a call to RUN_TRACE@ at the start of every routine

If so, does RUN_TRACE@ keep a running record of having seen routines before, and suppress output to the trace file on all but the first entry?

mecej4

The output from FTN95 /? is incorrect at this point. /RO makes calls to SYSTEM_INFO@ and not to RUN_TRACE@. /RU makes calls to RUN_TRACE@.

I can look further into these two routines if that helps but you may be able to get the quickest impression from the resulting output.

Paul, unless this facility is felt useful by other users, it is probably not worth the effort. Some of these custom subroutines (such as SYSTEM_INFO@) appear to be left over from the past versions of the compiler, unsupported and undocumented.

I read Dan's post, remembered reading something about an option for help with tracing programs, and responded.

Probably it's good to keep /RU for 64bit if for 32bits it is already mostly done.

As to my another suggestion 'Go back one line' in SDBG I will remind you one situation everyone had in the past where this feature will be very useful shortening debug when reading files with multiple READ statements and getting format mismatch. If you redirect the code when hitting error into some label ( say, label 100 )

READ(22,'(1pe10.3)',err=100) A
READ(22,'(1pe10.3)',err=100) A1
READ(22,'(1pe10.3)',err=100) A2
READ(22,'(1pe10.3)',err=100) A3
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
READ(22,'(1pe10.3)',err=100) A2114
READ(22,'(1pe10.3)',err=100) A2115
READ(22,'(1pe10.3)',err=100) A2116

...............................................
100 print*,' Error reading file'

you do not know at which line this error happened and trying to catch it in SDBG very slowly, step by step. Getting annoyed by the multiple pushing and clicking you start push buttons faster, then boooooom you miss the error and did not remembered at which line this was.

This is so annoying that I usually complicate the reading process with multiple my own debug options so that i count lines. But all these complications make source code very muddy

Dan,

I would expect that what you are asking is very difficult. The case you quote would need to recover the file buffer. If the line of code was an array syntax, there would be a lot to recover. Wouldn't an easier approach be: k = 0 ; READ(22,'(1pe10.3)',err=100) A k = k+1 ; READ(22,'(1pe10.3)',err=100) A1 k = k+1 ; READ(22,'(1pe10.3)',err=100) A2 k = k+1 ; READ(22,'(1pe10.3)',err=100) A3 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, k = k+1 ; READ(22,'(1pe10.3)',err=100) A2114 k = k+1 ; READ(22,'(1pe10.3)',err=100) A2115 k = k+1 ; READ(22,'(1pe10.3)',err=100) A2116

Then again I am not a frequent user of SDBG. ( In the past, /check and SDBG have messed with ALLOCATE which makes it difficult to reproduce the problems I typically have, producing new problems about stack and memory overflow. This compounds anything I may be trying to resolve.)

John

I will hide /RO and make a note that /RU needs porting to 64 bits.

/RU /64 has now been added for the next release.

Quoted from JohnCampbell Dan, I would expect that what you are asking is very difficult. The case you quote would need to recover the file buffer. If the line of code was an array syntax, there would be a lot to recover.

John, the request is to be able to view the last [5, 10 or such number] line numbers that were executed, not to step backwards, change the file pointer or instruction pointer.

Paul, Thanks for implementing /RU for 64bits. As to /RO if you would keep exactly the same approach as with /RU but report just the calls of subroutines this also would be useful. Currently /RO reports only first use of any subroutine. Please also look if one step back in debuggers can be tracked by the debuggers. Initially as mecej4 correctly notices just the 'Show previously executed line' or even just its the line number would be OK.

Quoted from JohnCampbell Dan,

I would expect that what you are asking is very difficult. The case you quote would need to recover the file buffer. If the line of code was an array syntax, there would be a lot to recover.

John, Though 64bits potentially offering us 4 billion times more RAM space then 32bits (looks like virtually unlimited amount for the next 50 years or so) completely recovering previous line of source sometimes would be indeed not easy task. For the simple cases of scalar a=b+c making copies of a,b,c is not a problem. If a,b,c are allocatble matrices, as you correctly noticed, this would be harder. But hopefully in the future this will be still doable, do we have any problems with memory or stack sizes? I did not expect to do exactly that hardest part, i'd just try to discuss feasibility to at least report the line as mecej4 pointed. And may be to try to implement the simplest part with the scalars.

Quoted from JohnCampbell

Wouldn't an easier approach be: k = 0 ; READ(22,'(1pe10.3)',err=100) A k = k+1 ; READ(22,'(1pe10.3)',err=100) A1 k = k+1 ; READ(22,'(1pe10.3)',err=100) A2 k = k+1 ; READ(22,'(1pe10.3)',err=100) A3 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, k = k+1 ; READ(22,'(1pe10.3)',err=100) A2114 k = k+1 ; READ(22,'(1pe10.3)',err=100) A2115 k = k+1 ; READ(22,'(1pe10.3)',err=100) A2116

I implicitly mentioned that I sometimes use this approach. Even more, I pushed it forward so that you do not need to count lines in the code and guess if this was right like or plus/minus one. Even SDBG64 still often misses by one line. If reading error happens the file automatically open editor at exactly this line marking it in red color. All done with Clearwin. You will even enjoy when the error happens how beautiful this thing is knowing how much miserable time you would spend searching for format mismatch hell knows where. So, the final result is beautiful, but the source code smells that you do not like to touch or even look at it. 😦

As you can expect, that additional hemorrhoid is hard to justify in 100 other uses of READ specifically with FIXED format sources. First, you will need to do your 'k=k+1' in additional line of text, second you better not to call line number as 'k' but give it some longer name to avoid possible interference and then you will end up not with beautiful text like you show above but with a messy long one you will hate to visit. How about Silverfrost to implement this functionality so that in case of error their %eb editor opening file at offending line? That will be cool feature

Quoted from JohnCampbell

Then again I am not a frequent user of SDBG. ( In the past, /check and SDBG have messed with ALLOCATE which makes it difficult to reproduce the problems I typically have, producing new problems about stack and memory overflow. This compounds anything I may be trying to resolve.)

Now debugger has no problems with allocatables