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: 1667
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: 650

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: 5095
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
DanRRight



Joined: 10 Mar 2008
Posts: 1667
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: 1667
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: 5095
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
DanRRight



Joined: 10 Mar 2008
Posts: 1667
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
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