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 

WinIO hanging for a long time when using very large stack

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



Joined: 25 Feb 2016
Posts: 110

PostPosted: Sat Aug 27, 2016 9:31 pm    Post subject: WinIO hanging for a long time when using very large stack Reply with quote

Using a very simple programme (below) the app becomes unresponsive for a few to tens of minutes at a time on launch when the stack size is increased.

I do not see any CPU or memory increases in the Windows Task Manager though.

Code:

      WINAPP 'CWP_ICO.RC'
     
      PROGRAM factor1
      IMPLICIT NONE
      INCLUDE <windows.ins>
      INTEGER ans
      ans=winio@('%ca[Number Factoriser]')
      END


This seems be to be occurring when the first Windows API call is made (in this case, winio kicks off the calls). Is this because the app is being relocated in memory to avoid conflicts with the DLLS?

Linking with this causes the problem (the stack size is from a real app, hence the reason for testing with this);
Code:
slink factor.obj -STACK:0x40000000


Linking with this runs OK and is responsive immediately;
Code:
slink factor.obj


This is a problem we are having in some older code that uses a lot of stack space (hanging on startup) and I have reduced it to this in an attempt to find a fix.

I assume I am doing something silly, can anyone shine any light on this? I'm hoping I can specify an origin / code base and avoid what I think might be code relocating itself in memory.

Thank you in advance.

Ryan
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Aug 27, 2016 10:31 pm    Post subject: Reply with quote

Could be your error. Usually I declare stack differently

slink prog.obj /stack:850000000

See, my stack is potentially orders larger (unless our different syntax means different things) and all works OK.
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Sat Aug 27, 2016 11:07 pm    Post subject: Reply with quote

I tried your syntax and converting it to decimal (as below) but the same results.

I forgot to add, this is Windows 10.

Code:
slink factor.obj /stack:1073741824
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Aug 27, 2016 11:31 pm    Post subject: Reply with quote

I see. This is the size of > 1GB. Sometimes it works with even larger 1.1-1.2GB stack, sometimes /3GB linking switch also helps to get the size of storage up to 1.9GB and make stack area less crowded . Small changes in stack or arrays both ways also sometimes help. Stack is like crazy sensitive wild horse why all here hated it waiting for 64bit compiler.

If nothing will help after many attempts then, well, the solution possibly could be to use new 64bit mode which I did not try yet (waiting for the full debugger) and do not use stack at all
Back to top
View user's profile Send private message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Sat Aug 27, 2016 11:47 pm    Post subject: Reply with quote

It seems to be something to do with a new thread being created for the WIN API calls made by winio. That thread is inheriting the large stack reservation and somehow doing a big delayed initialisation / reservation on it.

The Intel Fortran compiler also has the same issue by the looks of it;
Code:
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/285189


The Fortran code itself is very old and I won't be looking forward to trying to bring it up to 64 bit as I understand very little Fortran. Hopefully I can find a linker parameter to tweak instead.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Aug 28, 2016 12:01 am    Post subject: Reply with quote

I had this problem many years back. Someone still had it here too. Most probably it's conflict with the Windows. Heard with one ear that 64bit Clearwin+ does not have it.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sun Aug 28, 2016 4:54 am    Post subject: Reply with quote

What version of the compiler are you using? If it is NOT the new 8.x, then there is an issue with stack corruption in very specific circumstances. This was corrected in the latest version, and can SOMETIMES cause what you are seeing.

Also, it is possible to exceed the bounds of various controls with no errors being thrown, yet the code will become sluggish and non-responsive.

I understand that posting the full extent of the code is not possible, but there are a number of things that can go wrong and for which there is no apparent solution (or documentation, different issue); yet, there is a reason! Sometimes, it's just finding the key.

Also, think of what happens if you are on a machine without a large amount of main memory (after all, your stack at 1 gb, the program, the OS, ...). Are you thrashing the program by having it use the paging file?

I assume that the program does not do its job if you let the stack default.....
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Aug 28, 2016 12:16 pm    Post subject: Reply with quote

Ryan,

This may not be helpful, but my approach is always to minimise the use of the stack. Wherever possible I replace large (actually any) local or automatic arrays with ALLOCATE, as I find this a much more robust approach.
Again, my apologies if this is not suitable approach, but eliminating the stack usage for all large arrays is the safest approach. This should not introduce any adverse side effects, even with old legacy code.

The example you have posted also points to a likely problem with 'CWP_ICO.RC'. I could not find a copy of this in FTN95
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Mon Aug 29, 2016 5:18 pm    Post subject: Reply with quote

Just because I just thought of a question:

Is it possible that you are in the CHECKMATE phase, and the very large stack is getting initialized to "the unknown data pattern".

Granted that initializing a gig of memory should be fairly quick, but perhaps compiling and running in RELEASE mode might show this as a possible cause to the observed effect.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support 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