Bug reports from the dark past

Have anyone experienced program crash with the bug report on some obvious error like array limit violations months or years after the program was working OK and definitely was checked many times with /check /full_debug /undef ? in 25 years of using this compiler I had that devilry dozen times. Are these bad compiler switches for bound violation? When program crashed using them immediately revealed the offending line. But this line was there for a year !

During last 6 months I has another abruptly appeared error on forgotten declaration of some real*8 function as external. All worked seems OK every day and then abruptly it did not.

I don't have any insight into these problems. There is no reason to think that there is anything wrong with these switches. We aim for perfection but it is a little way off.

I am just trying to understand this very rare kind of problems. That phenomenon could be related to some confusing circumstances. For example indeed i used these debugging switches but the error occurs in very rare combination of parameters or very late in time. Besides the code exhausted all the resources of 32bit system 20 years ago. It's a witchcraft to make it to just load sometimes.

Dan,

I would suspect there is an array out of bounds. I've had this many times before. I have written programs allowing an array, based on a time variable, such as years or days, to be larger than I then expected it might become. not realising how old I could become !! It is not the compiler, but our longevity that is the problem.

John

Run-time checks such as those performed when /check and /undef are used always have the limitation that a run with no errors trapped only establishes that the specific run did not run into errors while exercising a particular portion of the program code and for a particular set of values of input data. With different input data, latent errors may surface in the same portion of the code, or other portions of the code may be exercised and display additional errors.

As John points out, code that depends on the date, time or phase of the moon may cause errors only in certain runs. Here, for example, is a small program that runs **today **with no errors.

program clk
implicit none
real(kind=2) :: dr
integer :: i,n,iv(10)=(/(i+5,i=1,10)/)
call seconds_since_1980@(dr)
n=10
if(dr.gt.1.0932e9)then
   n=n+5
   do i=5,n
      iv(i)=2*iv(i)
   end do
else
   do i=3,n
      iv(i)=3*iv(i)
   end do
endif
write(*,'(10I4)')iv
end program clk

Tomorrow, if the same program is compiled and run with no checks, it may well say 'Error 95, Unit has neither been OPENed nor preconnected'. With /check, it will show an array bound being violated.

I spent time and found that the array violation error was always there but surfaced at very specific set of parameters. Before the code never touched that far end of indexes.

I always had an impression that compiler can abruptly find me some very surprising error in older part of code while it did not for years. Since code is large and I did not spend much time to investigate I have no proof that the error was always there. When compiler finds the error you are happy to forget that immediately.

An impression though is not always reality and I kept my eyes open.

Suspicion was based on numerous internal bugs of older FTN95 and the large code size and arrays which were near the limits of stack and 32bit OS. During last decade thanks to increased users base a lot of bugs, mostly Fortran 90/95 related (the Fortran 77 part of FTN95 was pretty stable) were pesticided. The code was still increasing and increasing. I do not know right now how it actually works sometimes, it shouldn't. I actually need 64 bit compiler for decades but afraid to move to the ones from other companies since I tried before all of them and did not like them very much

But the example from this thread seems is my own problem.

Which is good.

1. Still trying to catch the devil by his tail. Well, just found potentially one confirmation of my suspicion.

Upgraded compiler and while comping it found me obvious error which previous versions missed for 1-2 years. The code had declaration

integer li(100)

while in source code i by mistake tried to allocate 101 elements

1061.    allocate ( Approx_Auio_at(Nl,izd), stat = li(101)) 
      

*** Array subscript for first rank of LI, 101, is greater than the declared upper bound, 100 *** Array subscript for first rank of LI, 101, is greater than the declared upper bound, 100 2 ERRORS, 43 WARNINGS [<main program>

Will investigate how missing this so elementary bug was ever possible.

2. The 7.1 now conflicting with the font smoothing(aliasing) declarations

3.   c_external nARGB@              '__nargb'(VAL,VAL,VAL,VAL):integer
   

*** Return type is expected. Found (VAL,VAL,VAL,VAL):INTEGER 9830) c_external SET_SMOOTHING_MODE@ '__set_smoothing_mode'(VAL):integer *** Return type is expected.

I was early adopter of this feature starting from beta, and all worked OK. Was something changed in the latest version ?

3. This was fixed in previous versions but looks like it broke in 7.1 again: if %gr has declared with full_mouse_input then right click (the %pm is used in the code for that) does not work if mouse is on the graphics surface. %pm only works if mouse is taken away from graphics screen into text window territory. (could be also my own devilry) The thread where we discussed this before is here https://forums.silverfrost.com/Forum/Topic/1286&highlight=fullmouseinput

Dan,

Regarding No 3, did you have the option 'popup' in your %gr?

I was saddened to be reminded of the contribution and help many of us got from the late John Horspool.

Eddie

I forgot popup, thanks Eddie. But suspect i will forget it again and again. And again. And again 642 times. Because this feature is for full_mouse_input only.
So my suggestion would be to add its functionality permanently and remove from the %gr list. Or may be add into different place like %pm[popup]

John was great fellow of this group. Pity we don't spend enough on cancer research. Some developments here are pretty advanced already and showed 90% cure rate on test animals almost a decade ago but progress is too slow as i learned this year contacting few top researchers in this area which i know personally after one of our colleagues got ill...

The reason for that is clear to me: basically people don't care that they don't live longer, perhaps forever, that they get ill and they die. They leave quietly and some even happily. They do not move a finger to change anything. They take all that as given. They do not realize that the paradise they were hoping for was actually here and it was necessary to make it happen here... And why they don't care is a different story.

I have few brilliant solutions in my codes John suggested so if people will still use them in future the source code will still keep comments like this

!
!       With thanks to John Horspool 2008-04-02
!

Quoted from DanRRight

1. The code had declaration

integer li(100)

while in source code i by mistake tried to allocate 101 elements

1061.    allocate ( Approx_Auio_at(Nl,izd), stat = li(101)) 
      

*** Array subscript for first rank of LI, 101, is greater than the declared upper bound, 100 *** Array subscript for first rank of LI, 101, is greater than the declared upper bound, 100 2 ERRORS, 43 WARNINGS [<main program>

A couple of comments: it is a misstatement to say that you tried to allocate 101 elements. The declaration of array li() is for 100 elements. The allocation statement attempts to put the status returned by the ALLOCATE statement into a location beyond the end of the array. In fact, if the STAT= clause were left out, there would be no error at all.

Secondly, the compiler is incorrectly counting the number of errors as 2, and prints the error message twice.

Thirdly, you helped the compiler to spot the subscript overrun by coding the constant 101 into the statement. Had you, instead, declared an integer variable, say, IST, set IST=101 and then and put ...,STAT=li(IST) in your ALLOCATE statement, the compiler would not have found the error except at run time and then only if you had subscript checking turned on.

Well, strictly saying, I still did not catch the devil for the tail. He escaped. The major point here is that this was not a so called 'clean experiment': i was using new version of compiler. Definitely something might be changed there as it is permanently improving. To have perfectly pure experiment, i'd need to get the error with the same compiler version.

Look he is laughing hanging on the tree upside down

'We have 999 registered users'

lol 😃