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 

Bug reports from the dark past

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



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Aug 21, 2014 3:23 am    Post subject: Bug reports from the dark past Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Aug 21, 2014 7:57 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Aug 21, 2014 10:56 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Aug 22, 2014 1:43 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Aug 22, 2014 2:53 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Aug 23, 2014 1:10 am    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Aug 27, 2014 12:20 pm    Post subject: Reply with quote

" 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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Aug 27, 2014 4:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Sep 03, 2014 1:22 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Wed Sep 03, 2014 3:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Sep 03, 2014 4:08 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Sep 03, 2014 4:47 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Sep 03, 2014 11:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Sep 06, 2014 6:28 pm    Post subject: Reply with quote

Look he is laughing hanging on the tree upside down

"We have 999 registered users"

lol Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General 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