forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incorrect/missing line numbers in traceback after abort

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sun Sep 09, 2018 10:43 am    Post subject: Incorrect/missing line numbers in traceback after abort Reply with quote

The following test program contains an error in the declaration of the size of an array dummy argument. When the program is compiled and run with /debug /check, the line numbers in the traceback are not consistently reported.

First, the source:
Code:
      PROGRAM DRIVR
      implicit none
      integer, parameter :: NCL = 101
      REAL T(NCL)
      call stcomp (t)
     
      CONTAINS
      SUBROUTINE STCOMP(V)
      IMPLICIT NONE
      REAL V(501)            ! bug here, should have been (101) or (NCL)
      INTEGER :: I
      do i = 1, NCL
         V(i) = 0.02*(i - 1)
      end do
      return
      end subroutine stcomp

      end program drivr

When compiled and run at the command line, FTN95 8.30 (32-bit) gives
Code:
Runtime error from program:s:\nls\difcor\tst1.exe
Run-time Error
Attempt to call a routine with argument number one containing too few array elements
 DRIVR~STCOMP -  in file tst1.f at line 7 [+004d]
 main -  in file tst1.f at line 5 [+0047]

This is odd since Line-7 contains "CONTAINS" and is not even an executable statement.

If we now add the option /64, the traceback is
Code:
Within file tst1.EXE
in DRIVR~STCOMP at address f8
in DRIVR in line 5, at address 4e

Note that the first item shows only an address and no line number.

When the same EXEs are run in SDBG/SDBG64, the tracebacks are different.

SDBG-32 shows only one line number in the traceback, namely, Line-5.

SDBG-64 shows the full traceback with correct line numbers.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Sep 10, 2018 8:50 am    Post subject: Reply with quote

Thank you for the feedback. I have made a note of this error.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Sep 10, 2018 9:32 am    Post subject: Reply with quote

Mecej4,

Out of interest, where does the error occur? When the subroutine is called, at the entry point of the subroutine, or where the size of the array is declared? If the latter, in the calling program or in the subroutine?

Is a blank line a line at all in this context? If not, then line 7 is the Subroutine start (/64) whereas line 5 is the Subroutine call (/32). So maybe there are different answers to my first question above.

I think that with the message "Attempt to call a routine with argument number one containing too few array elements" I would find the programmer error more easily if the name of the subroutine were given rather than a line number, especially if the name included the container, which needn't be the main program in the general case)

(Noted the split infinitive, by the way. Can I have pedant of the day award please?)

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Mon Sep 10, 2018 11:26 am    Post subject: Reply with quote

The error occurs in http://www.netlib.org/a/difcor . This is a Fortran-4 source code written for a CDC mainframe, even though it was published in the 1980-s. In addition to the error about the dummy array size, which I encapsulated in the test code, the DIFCOR program contains usage of some uninitialized variables, expects 48-bit precision for REAL, and declares the names of files as arguments in the PROGRAM statement. FTN95 is very helpful in getting such old codes working on a PC.

Line-numbers: think of each line as a card image, and imagine that every card, blank or not in cols. 1-72, contains a seq.no. in cols. 73-80. The line number is what would have been the seq.no. on the corresponding card. One hopes that every text editor and source code pane in an IDE or debugger would display the same line number for a given file. The various tools in a single compiler package ought to share one definition of line number.

Tracebacks: In Fortran-4, all subprograms had implicit interfaces. Subprograms were compiled separately. Calls from other subprograms had to be compatible with the implicit interface of the callee. An incompatible argument list in a CALL (or function reference) is an error in the CALL statement (or function reference); but, with separate compilation, the subprogram has be entered before the arguments can be checked for compatibility. Ideally, the runtime should present the line numbers of the back-trace, starting with the line containing the declaration of the incompatible dummy argument and that argument should be named. If that is too hard to do, one could settle for the line number of first executable statement of the subprogram, or just the name of the subprogram, and the ordinal number of the argument.

[For Eddie]

Split infinitives: They may provide welcome distraction from splitting hairs. As H.W. Fowler said, "The split infinitive is an ugly thing ... but it is one among several hundred ugly things" ( www.bartleby.com/116/503.html ). The error message reminds me of "For sale, piano, by a lady with wooden legs".


Last edited by mecej4 on Mon Sep 10, 2018 2:39 pm; edited 2 times in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Sep 10, 2018 1:31 pm    Post subject: Reply with quote

I get a 404 for the web reference, and when I run your test program it runs for me without error when neither debug nor check is specified. When I use those two additional options in I get the error report presented in a Windows version of the Silverfrost Debugger, with the highlighted offending line better in the 32 bit version at line 5 (no line numbers given with that version), or on the DO loop line (line 12, and not your line 7) in the 64 bit version, which does have line numbers. The Windows debugger pops up even though I compiled at the command line. Odd. The variables window is more helpful in the /64 version than the /32, but the highlight better in /32. In both cases finding the bug would be easy, even ignoring your helpful comment! So agreed, they are reported inconsistently.

Yes, I remember giving names for files in the PROGRAM statement - some other compilers didn't need a program statement at all.

I'm surprised that a CDC expected 48 bit for a REAL, as the CDCs I used all used one 60-bit word. (6400, 6500, 6600 and 7600 machines used). The Elliot and ICL computers I used back then had 2 x 24-bit words for a REAL, but this wasn't what I expected from anything US-made.So I researched earlier CDC computer systems and they had 24 bit or 48 bit words, thus using 48 bit single precision REALs like contemporary UK computers.

The late Professor Zienkiewicz (noted for his work on the Finite Element method and related books and papers) once told me in conversation that as most US Universities used computers with 32-bit REAL precision, some of the algorithms he published didn't work for them, and he was subjected to a barrage of complaints that his published results (obtained with higher precision on ICL 1900 series machines) were not repeatable. Perhaps Zienkiewicz's correspondents couldn't afford CDC, and were cursed with some other brand, it not being a mistake (anecdotally) to specify IBM.

Although you have identified an error, it may not have mattered on the CDC architecture with their compiler. The same goes for uninitialised variables, as many compiler/computer combinations initialised everything to zero (see posts previously about what FTN95 does).

Your section headed 'Traceback' is useful, as I hadn't considered separate compilation. I suspect that having a CONTAINSed subroutine in a separate file would make this whole business harder to deal with.

When I was a card user, some compilers I used would gag at a completely blank card, and most of us eschewed them as they could violate some arbitrary limits as to how many cards one could submit, or worse in a commercial setting, could involve extra charges. One of the very positive things in modern Fortran is that it permits completely blank lines, not even needing to be blank comments.

As a matter of fact, provided that NCL does not exceed 101, it doesn't seem to matter with FTN95 without the additional switches, and since NCL has scope inside and outside the CONTAINSed subroutine, this could be an extraordinarily difficult bug to find if, say, NCL was set to greater than 501 when defined. (And I appreciate it is a demonstrator).

Regarding the uninitialised variables, it would have been a minor step in any revision of the Fortran standard to require all variables to be initialised to zero and the problem would then go away, because as far as I'm aware, they either aren't initialised at all, or they are initialised to zero, and they sure aren't initialised to anything else!

As far as reporting errors consistently between the two versions, I think it is more important that error reporting is done usefully than consistently (which I take to mean identically). I understand that /64 is a completely new and clean sweep as far as code generation etc is concerned, although that's only what I inferred. As such, it is more valuable to me than a simple extension of the 32 bit version, as it means I now have 2 separate compilers to run my code through. Other vendors' compilers are us
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Mon Sep 10, 2018 2:45 pm    Post subject: Reply with quote

I have fixed the URLs.

The CDC 6000 X registers were 60 bits long, of which 48 bits were used for the mantissa, 11 for the biased exponent, plus a sign bit. See the page numbered 3-15 in the manual, http://bitsavers.trailing-edge.com/pdf/cdc/cyber/cyber_70/60100000AL_6000_Series_Computer_Systems_HW_Reference_Aug78.pdf .

The DIFCOR program uses 2^(-48) for, in effect, machine epsilon.


Last edited by mecej4 on Mon Sep 10, 2018 3:30 pm; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Sep 10, 2018 3:01 pm    Post subject: Reply with quote

"I have fixed the URLs" - now I wish you hadn't. What a horrible coding style.

E
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Mon Sep 10, 2018 3:31 pm    Post subject: Reply with quote

Eddie, I just noticed: your long post of today has been truncated in mid-sentence!
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Sep 10, 2018 10:32 pm    Post subject: Reply with quote

Thanks Mecej4, it should end:

Other vendors' compilers are useless when you get into Clearwin+.

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Tue Sep 11, 2018 2:37 am    Post subject: Reply with quote

On the 1970's compilers I used, declaring "REAL V(501)" would have not caused any problems, as V being an argument would have had memory allocation in the calling routine. As there was no array syntax, 501 was just an arbitrary dimension.
CONTAINS was not available in the compilers I used, so NCL would have needed to be an argument or in COMMON, which defines the size used.
This error only occurs when adopting F90 syntax.

Eddie, not sure I agree with your Zienkiewicz experience, as struggles with different REAL word sizes was a very common problem, perhaps except for those ignorant ones rusted onto IBM ! ( not us Salford users who were familiar with many reals )
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Thu Nov 08, 2018 11:19 am    Post subject: Reply with quote

I have looked at the program posted by mecej4 and there is indeed an incorrect traceback in this instance. Fortunately both SDBG and SDBG64 give the correct point of failure.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group