View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Aug 21, 2014 3:23 am Post subject: 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Aug 21, 2014 7:57 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Aug 21, 2014 10:56 am Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Aug 22, 2014 1:43 am Post subject: |
|
|
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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Aug 22, 2014 2:53 pm Post subject: |
|
|
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.
Code: | 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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sat Aug 23, 2014 1:10 am Post subject: |
|
|
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. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Wed Aug 27, 2014 12:20 pm Post subject: |
|
|
" 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."
So the answer must be therewith this function and it's declaration. You need to look critically at how. It's not easy Iknow as we all have an inbuilt mechanism in our own CPU's which tends to read and interpret what we want to see ! Which is the beauty of these forums where someone else can see the obvious which passes us by .
Any more details of the specific latest problem ? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Aug 27, 2014 4:19 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Sep 03, 2014 1:22 am Post subject: |
|
|
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
9829) 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
http://forums.silverfrost.com/viewtopic.php?t=1551&highlight=fullmouseinput
Last edited by DanRRight on Wed Sep 03, 2014 6:53 pm; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Sep 03, 2014 3:36 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Sep 03, 2014 4:08 pm Post subject: |
|
|
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
Code: |
!
! With thanks to John Horspool 2008-04-02
!
|
Last edited by DanRRight on Thu Sep 04, 2014 12:58 am; edited 5 times in total |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Sep 03, 2014 4:47 pm Post subject: Re: |
|
|
DanRRight wrote: | 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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Sep 03, 2014 11:46 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sat Sep 06, 2014 6:28 pm Post subject: |
|
|
Look he is laughing hanging on the tree upside down
"We have 999 registered users"
lol |
|
Back to top |
|
|
|