View previous topic :: View next topic |
Author |
Message |
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sat Aug 27, 2016 9:31 pm Post subject: 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.
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;
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Sat Aug 27, 2016 10:31 pm Post subject: |
|
|
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 |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sat Aug 27, 2016 11:07 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Sat Aug 27, 2016 11:31 pm Post subject: |
|
|
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 |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sat Aug 27, 2016 11:47 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Sun Aug 28, 2016 12:01 am Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Aug 28, 2016 4:54 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Aug 28, 2016 12:16 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Aug 29, 2016 5:18 pm Post subject: |
|
|
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 |
|
|
|