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 

What sometimes 64bit mode with /check /full_debug generates

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



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

PostPosted: Fri Jan 12, 2018 8:09 am    Post subject: What sometimes 64bit mode with /check /full_debug generates Reply with quote

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

Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Fri Jan 12, 2018 8:50 am    Post subject: Reply with quote

I'm sorry Dan I'm laughing my socks off here in good 'ol europe.

The question that spring rolls into my mind is: are there actually 31 to be expected or is that wrong too ? I don't think I've ever seen in my life a routine with even 31 arguments.
If 31 is incorrect as well this could be the worlds first discovery of a double-bug ?

(P.S. is a 'devil bug' more correctly referred to as a 'dug' ? which would be very appropriate as the more they're investigated the deeper the hole to the solution gets lol Smile )
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Jan 12, 2018 9:28 am    Post subject: Reply with quote

Dan

We would need some working code in order to fix this.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Sat Jan 13, 2018 12:23 am    Post subject: Reply with quote

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


Last edited by DanRRight on Sat Jan 13, 2018 1:18 am; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Jan 13, 2018 12:35 am    Post subject: Reply with quote

[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
Code:
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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Jan 13, 2018 9:58 am    Post subject: Reply with quote

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



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

PostPosted: Sat Jan 13, 2018 10:44 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Tue Feb 13, 2018 2:15 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
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.


Last edited by mecej4 on Tue Feb 13, 2018 2:54 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Feb 13, 2018 2:39 pm    Post subject: Reply with quote

Mecej4, was it 1000+ parameters when around 30 only was expected problem which i started this thread ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Tue Feb 13, 2018 2:58 pm    Post subject: Reply with quote

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



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

PostPosted: Tue Feb 13, 2018 10:56 pm    Post subject: Reply with quote

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



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

PostPosted: Wed Feb 14, 2018 2:13 pm    Post subject: Reply with quote

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
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 -> 64-bit 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