Prev: limitations of 64bit gfortran
Next: C String Prefix Operator Idea (Was: gfortran diagnostics andso on)
From: Jugoslav Dujic on 10 Oct 2007 04:21
Colin Watters wrote:
| "Mike" <SulfateIon(a)gmail.com> wrote in message
| news:1191980696.066318.97550(a)y42g2000hsy.googlegroups.com...
| The trick when conducting experiments is to observe the results. Use DUMPBIN
| on the exe after each of the above operations, to verify they are having the
| effect you expect. When you can relyably set the stack size to any required
| value, then exercise the sensable range of stack sizes to find one that
| works. A 'sensable' range is somewhere between 2 GBytes minus the .exe's
| image size as an upper limit, and a bit above zero as a lower limit.

How about that we advice Mike to cure the cause rather than the symptoms?

Despite the ridiculously low default stack limit in CVF, I think that it
is *seldom* necessary to give so huge stack to the program. 1MB should IMO
suffice for a vast majority of problems. The first step should be to
investigate what caused the stack overflow and address the problem, rather
than cludge with linker or EDITBIN stack size.

<quoting myself from an earlier thread>
For similar situations that might occur in the future, just display
the "Call stack" debugging window -- somewhere in there you
will see the offending line from your code, and you can inspect the
values of variables in its context by double-clicking the entry...
or apply some common sense.
</quote>

Common causes for stack overflow are:
1) One-line large array operations, involving an automatic generation
of a temporary -- solution: rewrite it using a do-loop
2) Automatic arrays of extreme size: solution: make them allocatable
instead
3) Infinite recursion -- fix the problem, as the code is broken
anyway

Chances are that solution 1) will also increase the performance,
possibly with a factor of two. Solution 2) would mildly decrease
the performance, but normally negligibly. (Solution 3) is
self-evident).

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.
From: Mike on 10 Oct 2007 04:52
On Oct 10, 2:55 pm, "Colin Watters"
<qolin.see_signat...(a)nowhere.co.uk> wrote:
> "Mike" <Sulfate...(a)gmail.com> wrote in message
>
> news:1191980696.066318.97550(a)y42g2000hsy.googlegroups.com...
>
> <snip>
>
> > following is the result of dumpbin
> > Dump of file sv1p0b.exe
>
> > PE signature found
>
> > File Type: EXECUTABLE IMAGE
>
> <snip>
>
> > 0 size of stack reserve
> > 0 size of stack commit
>
> ...If we believe what DUMPBIN is saying here, your .exe has a stack size of
> zero. That will cause the sort of problem you are seeing. But I wonder if
> dumpbin is being confused?
>
> <snip>
>
>
>
>
>
> > In the help of Compaq Visual Fortran, it shows :
>
> > EDITBIN Option /STACK
> > This option sets the size of the stack in bytes and takes arguments in
> > decimal or C-language notation. The /STACK option applies only to an
> > executable file. This option takes the following form:
>
> > /STACK:reserve[,commit]
> > The reserve argument specifies the total stack allocation in virtual
> > memory. EDITBIN rounds up the specified value to the nearest 4 bytes.
> > The optional commit argument is subject to interpretation by the
> > operating system. On Windows NT 4 and Windows 2000 systems, commit
> > specifies the amount of physical memory to allocate at a time.
> > Committed virtual memory causes space to be reserved in the paging
> > file. A higher commit value saves time when the application needs more
> > stack space but increases the memory requirements and possibly startup
> > time.
>
> > I use :
> > editbin/stack:0xFFFFFFFF sv1p0b.exe
> > after the exe is generated by CVF.
> > Now it shows "forrtl: severe(157): program exception-access violation"
>
> > I also set the stack in GUI of CVF, which is in "Project
> > setting..Link...Output". It also shows "forrtl: severe(157): program
> > exception-access violation"
>
> > I also change the stacksize to be about 50000000 which is a bit larger
> > than 43227000 (size of image). Same error happens.
>
> > Mike
>
> The trick when conducting experiments is to observe the results. Use DUMPBIN
> on the exe after each of the above operations, to verify they are having the
> effect you expect. When you can relyably set the stack size to any required
> value, then exercise the sensable range of stack sizes to find one that
> works. A 'sensable' range is somewhere between 2 GBytes minus the .exe's
> image size as an upper limit

Could I ask why ? why 2GBytes? why minus?

Now I have tried stack size n.
A) if n=0, when it runs, error message show "stack overflow".
B) if I set n to be 50000000(decimal), it can run well.
C) if I set n to be 1126313984(decimal, as warning message shows), it
cannot run, showing not sufficient memory size.

So it's very important to calculate stack size. But how?

For C), I don't understand. Doesn't Windows XP take care of it by
virtual memory?

Mike

From: glen herrmannsfeldt on 10 Oct 2007 06:45
Mike wrote:

(snip)

> Could I ask why ? why 2GBytes? why minus?

> Now I have tried stack size n.
> A) if n=0, when it runs, error message show "stack overflow".
> B) if I set n to be 50000000(decimal), it can run well.
> C) if I set n to be 1126313984(decimal, as warning message shows), it
> cannot run, showing not sufficient memory size.

> So it's very important to calculate stack size. But how?

> For C), I don't understand. Doesn't Windows XP take care of it by
> virtual memory?

The sizes are in virtual memory. Windows XP allows at most 2GB of
virtual memory for one program. Most programs don't get close
to that, though some do take hundreds of megabytes. Web browsers
with many open pages tend to grow.

Look at the task manager, processes tab, and the VM size column.
If there isn't a VM size column add it with the View/Select columns
window.

-- glen

From: Louis Krupp on 10 Oct 2007 05:58
Mike wrote:
<snip>

> Now I have tried stack size n.
> A) if n=0, when it runs, error message show "stack overflow".
> B) if I set n to be 50000000(decimal), it can run well.
> C) if I set n to be 1126313984(decimal, as warning message shows), it
> cannot run, showing not sufficient memory size.
>
> So it's very important to calculate stack size. But how?

If stack size is that important, you're probably doing something wrong,
like allocating a huge array on the stack when it would make more sense
to allocate it dynamically from the heap.

If your program only has to run once on your computer and then never
again anywhere else, it might make sense to find a stack size big enough
to make it work just this once. If you or anyone else is going to be
running this program in the future, you'll be happier if you fix the
program so it runs with a default stack size.

Louis
From: Mike on 11 Oct 2007 20:18
On Oct 10, 5:58 pm, Louis Krupp <lkr...(a)pssw.nospam.com.invalid>
wrote:
> Mike wrote:
>
> <snip>
>
> > Now I have tried stack size n.
> > A) if n=0, when it runs, error message show "stack overflow".
> > B) if I set n to be 50000000(decimal), it can run well.
> > C) if I set n to be 1126313984(decimal, as warning message shows), it
> > cannot run, showing not sufficient memory size.
>
> > So it's very important to calculate stack size. But how?
>
> If stack size is that important, you're probably doing something wrong,
> like allocating a huge array on the stack when it would make more sense
> to allocate it dynamically from the heap.
>
> If your program only has to run once on your computer and then never
> again anywhere else, it might make sense to find a stack size big enough
> to make it work just this once. If you or anyone else is going to be
> running this program in the future, you'll be happier if you fix the
> program so it runs with a default stack size.
>
> Louis

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.

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.

Mike

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