Prev: limitations of 64bit gfortran
Next: C String Prefix Operator Idea (Was: gfortran diagnostics andso on)
From: glen herrmannsfeldt on 11 Oct 2007 22:10
Mike wrote:

(snip)

> This program is not written by me. It contains over 130 subroutine/
> functions, and I don't know how to check it.
> I am told this program never runs on Windows. It runs successfully on
> UNIX/Linux.

> I test again about the stack size n. If n is 2M, it runs OK, but it
> fails if n=1M. The exe is about 2M. So, can I say that stack size
> needs to be about exe size at least? Can I have a rule of thumb.

There is no rule. Very small programs can use a lot of stack
(if they put large arrays or even temporary arrays on the stack.)
Large programs might not use much stack, other than for
subroutine arguments and return addresses.

> According to the previous reply from Terence : "I have met the
> stack overflow problem. ..... I calculate about #4000 hex worth.
> My solution was to take the executable and add another #4000 (hex)
> space to the stack.
> This worked for me. "
> Is it the 2M+#4000(hex)?

> I surf the internet. And the Microsoft says that although people want
> to increase the VM when the program needs larger memory to run, it
> still suggests that let the system take care of it. Thank to glen, I
> have noticed that VM shown in task manager is about 1G for this
> program. And the Windows automatically switches the VM to 1.5G.

Do you mean the total VM used? The task manager (at least on W2K)
gives the individual per task sizes, both virtual (VM size) and real
(Mem usage).

-- glen

From: Mike on 11 Oct 2007 22:09
On Oct 12, 10:10 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu>
wrote:
> Mike wrote:
>
> (snip)
>
> > This program is not written by me. It contains over 130 subroutine/
> > functions, and I don't know how to check it.
> > I am told this program never runs on Windows. It runs successfully on
> > UNIX/Linux.
> > I test again about the stack size n. If n is 2M, it runs OK, but it
> > fails if n=1M. The exe is about 2M. So, can I say that stack size
> > needs to be about exe size at least? Can I have a rule of thumb.
>
> There is no rule. Very small programs can use a lot of stack
> (if they put large arrays or even temporary arrays on the stack.)
> Large programs might not use much stack, other than for
> subroutine arguments and return addresses.
>
> > According to the previous reply from Terence : "I have met the
> > stack overflow problem. ..... I calculate about #4000 hex worth.
> > My solution was to take the executable and add another #4000 (hex)
> > space to the stack.
> > This worked for me. "
> > Is it the 2M+#4000(hex)?
> > I surf the internet. And the Microsoft says that although people want
> > to increase the VM when the program needs larger memory to run, it
> > still suggests that let the system take care of it. Thank to glen, I
> > have noticed that VM shown in task manager is about 1G for this
> > program. And the Windows automatically switches the VM to 1.5G.
>
> Do you mean the total VM used? The task manager (at least on W2K)
> gives the individual per task sizes, both virtual (VM size) and real
> (Mem usage).
>
> -- glen

The task manager (XP) shows the real and VM of the exe are 3.2M and
1.1G respectively. And the Windows set VM to be 1.534G.

Mike

From: Wade Ward on 11 Oct 2007 23:46


"Mike" <SulfateIon(a)gmail.com> wrote in message
news:1192154978.002684.9600(a)z24g2000prh.googlegroups.com...
> On Oct 12, 10:10 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu>
> wrote:
>> Mike wrote:
>>
>> (snip)
>>
>> > This program is not written by me. It contains over 130 subroutine/
>> > functions, and I don't know how to check it.
>> > I am told this program never runs on Windows. It runs successfully on
>> > UNIX/Linux.
>> > I test again about the stack size n. If n is 2M, it runs OK, but it
>> > fails if n=1M. The exe is about 2M. So, can I say that stack size
>> > needs to be about exe size at least? Can I have a rule of thumb.
>>
>> There is no rule. Very small programs can use a lot of stack
>> (if they put large arrays or even temporary arrays on the stack.)
>> Large programs might not use much stack, other than for
>> subroutine arguments and return addresses.
>>
>> > According to the previous reply from Terence : "I have met the
>> > stack overflow problem. ..... I calculate about #4000 hex worth.
>> > My solution was to take the executable and add another #4000 (hex)
>> > space to the stack.
>> > This worked for me. "
>> > Is it the 2M+#4000(hex)?
>> > I surf the internet. And the Microsoft says that although people want
>> > to increase the VM when the program needs larger memory to run, it
>> > still suggests that let the system take care of it. Thank to glen, I
>> > have noticed that VM shown in task manager is about 1G for this
>> > program. And the Windows automatically switches the VM to 1.5G.
>>
>> Do you mean the total VM used? The task manager (at least on W2K)
>> gives the individual per task sizes, both virtual (VM size) and real
>> (Mem usage).
>>
>> -- glen
>
> The task manager (XP) shows the real and VM of the exe are 3.2M and
> 1.1G respectively. And the Windows set VM to be 1.534G.
Where are you reading this from? This is as close as I get:
http://www.zaxfuuq.net/fortran4.htm

--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


From: Terence on 12 Oct 2007 19:16
I wonder if Mike is exceeding some linker limit?
If the 50Meg stack assigment works but a higher value does not,
perhaps the higher value causes "0" to be stored?

Frankly I see no need for native Windows compilation to be used for
anything except possibly a main set-up program and general Windows
facility interfacing for later modules.

I prefer to use a native-windows compiled program to establish what is
required by the user and determine file usages, than call command-line
compiled DOS-type F77 programs via the CALL SYSTEM function to spawn
the programs that actually do the work I need, even if a TUI should be
needed within them. These daughter programs are very economic of
resources.

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: limitations of 64bit gfortran
Next: C String Prefix Operator Idea (Was: gfortran diagnostics andso on)