WinIO hanging for a long time when using very large stack

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.

      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);

slink factor.obj -STACK:0x40000000

Linking with this runs OK and is responsive immediately;

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

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.

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

I forgot to add, this is Windows 10.

slink factor.obj /stack:1073741824

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

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;

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.

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.

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.....

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

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.