Welcome to our forums
Clearly FTN95-64 is still in its teen age. Which means despite its pumped muscles it's sometimes crazy. If it's only happen with me then ...well...it's a devilry... hates me so much. Look at that....no, these 1189 (!!!) are not my code's arguments and under FTN95-32 all works fine
Dan
We would need some working code in order to fix this.
John, 31 arguments has my routine. Why so many? This was an idea to make universal graphics routine, so there are a lot of parameters to set the XY plot. And this is why a came eventually to more and more use of %pl as setting all 30+ parameters was always a pain.
Paul, will try to set the demo which is not easy task
[continued]
Paul,
The devilry with 1189 parameters is not happening if /check is not used and so this problem is not urgent. More urgent are few others.
I currently move some large code from 32bit to 64 and get few other (mostly minor) problems I never had before or had no chance to catch them as there always was not enough memory with 32bits to check everything. Let's start one by one.
First one is causing 'Run-time error 18: This routine has been entered recursively (-ANSI mode)'. This happens in respond of using slider %^sl with the following callback function when the slider moves and function plotXY plots something at different value of the slider
integer function CB()
common k_CB_Function_IS_Busy
if(k_CB_Function_IS_Busy.eq.1) then
goto 1000
endif
jj= plotXY()
k_CB_Function_IS_Busy = 0
1000 CB=2
end function
As you can see there is special variable k_CB_Function_IS_Busy which prevents the code to plot anything before plotting at the previous position of slider is finished. At this time k_CB_Function_IS_Busy becomes =0 and allows another plot.
But now the crash is happening immediately at the entry into the callback function CB and this mechanism of prevention of overlapping of multiple instances of plotting does not work and is doing that brutal way: crash. I used this mechanism with 32bits very broadly before and do not see any other ways to do that easily.
Or this is happening only in /DEBUG mode to check for possible recursive errors as without /DEBUG all seems work OK? May be to solve this problem the RECURSIVE subroutines have to be used? Here also our Fortran language Nazi pros may help.
Dan
'One at a time' is good for me but the sample code still leaves me with the task of constructing a program around it. I need something that I can copy and that immediately demonstrates the issue.
A complicating factor for me is that it is quite possible that the bug (if there is one) has already been fixed. This means that I might be looking for something that is no longer there.
You are right, Paul: the demo examples must be always present because mostly all errors are users' fault, specifically in my cases. Will try to make it
Update. Unbelievable, the 32bit code works, 64bit not, but I can not reproduce 64bit bug on small example...it works ok. Now I wish again that compiler had verbose mode and tell what specifically made it think that the execution of code became recursive.
Quoted from PaulLaidler Dan
'One at a time' is good for me but the sample code still leaves me with the task of constructing a program around it. I need something that I can copy and that immediately demonstrates the issue.
A complicating factor for me is that it is quite possible that the bug (if there is one) has already been fixed. This means that I might be looking for something that is no longer there.
Paul, by chance, a month after this thread was started, (I think that) I have run into the same problem, but was able to fabricate a demonstrator for you to work with: http://forums.silverfrost.com/viewtopic.php?p=24009 . I may be jumping to conclusions here -- Dan's report is about the number of arguments, whereas my report is about the number of items in an array arguments but, depending on how the checking information is collected and passed, the two problems may be related.
Unlike Dan, I find that the bug is present in both 32- and 64-bit FTN95 8.10.
Mecej4, was it 1000+ parameters when around 30 only was expected problem which i started this thread ?
No, Dan, the number of arguments was only 2, and my error report is about /check causing an abort with 'argument with too few elements' rather than 'too many/too few arguments'.
Is it possible for you to share the source code that caused a report of 1189 arguments through Dropbox, etc.? I am interested in pinning this problem down, since I have run into it twice within a week, working on entirely different Fortran packages.
Mecej4, I worked on it last day, now trying to extract to simplify a bit the way till this run time bug occurs. So far the bud appears with 100% probability when I move subroutine to different locations. But as soon as I extracted this 31 input parameters subroutine and made for it small main program reproducer to launch it, the devilry disappeared...
No success yet. Added one more layer to reproducer: added the entire original subroutine which calls another subroutine where the bug happens but the bug still disappears. Interesting also that the bug does not happen even in the original big main code if offended subroutine is called by other then this callee subroutine. And of course everything works OK with 32 bits. Rear bug hunt like that requires high adoption rate of 64bits, a lot of active users who also use debugger. Good is that it is not affecting me too much, i can relatively easily take some workarounds here