Icreasing stack size

I would like to increase the stack size. There is a suggestion on the knowledge base that I haven't tried out yet, but this raises another question. Is there a facility somewhere that I can use to find out what the stack size actually is? This would allow me to find out whether my attempts (via stack/reserve/commit in SLINK) have actually worked.

All help gratefully received

The stack reserve is documented as 50Mb and I assume that this is still correct.

I do not know of an automatic way to find out what your program needs.

Paul,

Thanks. I have got around it for the moment, but it looks like I will have to try out 'virtual common' in due course.

Roger

Could someone post an example of using VC in SLINK and modifying the stack size. I tried this without success, although it was when also trying to test a large memory option. (3GB) Also, are values for stack provided in hex or decimal ? If decimal, how do we specify in hex, to get the 3 least significant digits zero.

When using SLINK virtual common, the parameters are optional and it is simpler to start by leaving them out. The command is vc in interactive mode and -vc on the command line.

The stack reserve can be presented in hex, decimal or even octal form.

0x3200000 (hex)

is the default which is 52428800 (decimal) or 50MB.

After almost 3 years of skirting around this problem, I finally need to solve it...

My program has suddenly started to give 'Floating point stack overflow' in the midst of a well used subroutine. There's nothing obvious wrong with the code, but there is a 50Mb database used in the program, which seems to be about the default size of the stack.

I have tried to invoke virtual common using Plato, but it requires a parameter to make it work, so I put 55000000 into the params line, (just to make it bigger than the default as indicated by Paul) and clicked Apply and OK. The rebuild in Plato tells me (in red) that 'VC:Base value rounded to 0x03474000', so it has clearly done something. It does not tell me that it is creating the DLL... and indeed the DLL is not in the folder where it should be or anywhere else, although it has deleted the old one. So, can anyone help, please?

My alternative is to increase the stack size. In Plato, the 'Set Win32 stack size' parameter is set to 510000000, which seems large enough. I increased it to 550000000 and still get the overflow, so what else is there to try?

Roger

I might be wrong about this but my first thought is to look for a fault in your program or (heaven forbid!) in the compiler.

If the floating point stack is overflowing then it means that it is not being cleared when it should be. A larger calculation could reveal a fault that has been there all along.

Finding bugs like this is extremely difficult but, as always, the diagnosis requires isolating the point of failure. If it is possible to construct a small program with the same fault then this helps enormously.

Paul, Thanks-you sent me off down a different search path and I found the problem in an undefined function call that had nothing to do with the subroutine where it crashed.

This solves the immediate problem, but I'd be grateful for some further advice. If in future, I want to change the stack size, am I correct in saying that I just change the (decimal) number in the Win32 stack size parameter in Plato?

Similarly, it seems that virtual common should have a similar effect. I guess that I set it in Plato again with some new parameter, but is it normal to get the red message and why did it not produce the DLL?

Roger

Roger

I don't recall the details off hand. After doing a build, take a look at the temporary file called BuildLog in the project folder.

Hopefully the FTN95 help file will provide the details for the given SLINK command line arguments.

By default I think that red messages are error reports which would be consistent with a failed FTN95 or SLINK command.