Fortran - Stack size, and warnings

Author

Stack size, and warnings

Dieter Britz

2006-09-28, 7:00 pm

1. My recursive program now runs, but when I increase the size
of the job, I get an "IOT trap", which I am told is likely
to be stack overflow. I am using the Intel 90/95 compiler,
and I work under Suse Linux 10.1. I think I need to write
something into the .bashrc file; what should this be, please?

2. The routine calls itself many times, with array sections
as arguments, and I get a lot of warnings that a temporary
array was allocated. I tried to suppress these with the -w
option, but they don't go away. Why not, and how do I stop
them?
--
Dieter Britz, Kemisk Institut, Aarhus Universitet

Rich Townsend

2006-09-28, 7:00 pm

Fly Away

2006-09-28, 7:00 pm

Steve Lionel

2006-09-28, 7:00 pm

Dieter Britz wrote:

> 2. The routine calls itself many times, with array sections
> as arguments, and I get a lot of warnings that a temporary
> array was allocated. I tried to suppress these with the -w
> option, but they don't go away. Why not, and how do I stop
> them?

Are these warnings coming out at compile time or at run-time? I think
the latter - they are controlled by the "-check arg_temp_created"
option and you may have turned on all run-time checking with -check or
--C.

However, these warnings are giving you a big clue, and rather than try
to suppress them you should try to determine why they are there and how
to rewrite your code to eliminate them.

What is happening is that you are passing a non-contigous array or
array slice to a routine that has either an implicit interface or an
explicit interface where the receiving argument is not an assumed-shape
array. (DIMENSION(:)). In this situation, the compiled code has to
create a contiguous copy of the array slice because the called routine
is expecting a contiguous array.

One solution is to have the called routine accept an assumed-shape
array and provide an explicit interface - then the array will be passed
by descriptor and no copy will need to be made.

Another solution is to see if you really need to be passing a
non-contiguous array here. Note that the compiler will generate
run-time code to test for contiguity if it doesn't know at
compile-time, so you should not get this warning unless the array
really is non-contiguous.

If you take either of these approaches, then the stack temp array will
not be created and your program will use much less stack.

A third option, which I don't recommend unless you have exhausted the
others, and which works only in the latest Intel compiler (9.1.037 on
Linux), is to tell the compiler to allocate array temporaries on the
heap rather than the stack. In 9.1.037, you have to use the
undocumented switch:

-Qoption,f,"-heap_arrays 0"

In future updates, you'll be able to simply use -heap-arrays
(/heap-arrays on Windows).

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
My Fortran blog
http://www.intel.com/software/drfortran

Dieter Britz

2006-09-29, 4:03 am

Dieter Britz wrote:

> 1. My recursive program now runs, but when I increase the size
> of the job, I get an "IOT trap", which I am told is likely
> to be stack overflow. I am using the Intel 90/95 compiler,
> and I work under Suse Linux 10.1. I think I need to write
> something into the .bashrc file; what should this be, please?
>
> 2. The routine calls itself many times, with array sections
> as arguments, and I get a lot of warnings that a temporary
> array was allocated. I tried to suppress these with the -w
> option, but they don't go away. Why not, and how do I stop
> them?

OK, the second point has been answered, I removed the -C
option and I no longer get the warnings.

I tried also to put in the unlimit command, but I still get
the same error, IOT trap. At the same time, I get on the screen
this:

db@kembritz:~/tut> *** glibc detected *** ./a.out: corrupted double-linked
list: 0x080af1a8 ***
======= Backtrace: =========
/lib/libc.so.6[0x402aa911]
/lib/libc.so.6[0x402abb70]
/lib/libc.so.6(__libc_free+0x84)[0x402abf84]
../a.out[0x805d650]
../a.out[0x805d5c5]
../a.out[0x804b783]
../a.out[0x804c7e3]
../a.out[0x804bf20]
../a.out[0x804b3a9]
../a.out[0x804c7b8]
../a.out[0x804c7e3]
../a.out[0x804a27f]
../a.out[0x8049d11]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4025c87c]
../a.out[0x8049c51]
======= Memory map: ========
08048000-080a1000 r-xp 00000000 03:05 400599 /home/db/tut/a.out
etc

Is this telling me something besides a stack problem?
--
Dieter Britz, Kemisk Institut, Aarhus Universitet

glen herrmannsfeldt

2006-09-29, 8:01 am

Dieter Britz wrote:
(snip)

> I tried also to put in the unlimit command, but I still get
> the same error, IOT trap. At the same time, I get on the screen
> this:

> db@kembritz:~/tut> *** glibc detected *** ./a.out: corrupted double-linked

I think this means the list used to keep track of memory allocation
has been corrupted, which usually means going outside of an array.

> list: 0x080af1a8 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x402aa911]
> /lib/libc.so.6[0x402abb70]
> /lib/libc.so.6(__libc_free+0x84)[0x402abf84]
> ./a.out[0x805d650]
> ./a.out[0x805d5c5]
> ./a.out[0x804b783]
> ./a.out[0x804c7e3]
> ./a.out[0x804bf20]
> ./a.out[0x804b3a9]
> ./a.out[0x804c7b8]
> ./a.out[0x804c7e3]
> ./a.out[0x804a27f]
> ./a.out[0x8049d11]
> /lib/libc.so.6(__libc_start_main+0xdc)[0x4025c87c]
> ./a.out[0x8049c51]
> ======= Memory map: ========
> 08048000-080a1000 r-xp 00000000 03:05 400599 /home/db/tut/a.out
> etc

> Is this telling me something besides a stack problem?

If you compile and link with -g you should get names and
statement numbers in the backtrace, though it may not indicate
the actual cause of the problem.

-- glen

Richard Maine

2006-09-29, 7:01 pm

Dieter Britz <britz@chem.au.dk> wrote:

>
> OK, the second point has been answered, I removed the -C
> option and I no longer get the warnings.

I strongly second Steve's advice on this. The warnings are there for a
reason. Just telling the compiler to be quiet about the problem is like
driving with your eyes closed because you find it too scary to drive
with them open. If you fully understand why you are getting the
warnings, and have judged that the thing being warned about is ok in
your case, that is one thing. I do that wilh some kinds of warnings. But
to ignore them without understaning them is very dangerous.

In the case of the specific message you are talking about, odds are high
that ignoring the warning will cause performance problems. And yes, it
will also probably greatly increase your stack usage.

Steve did explain how to fix the problem as opposed to ignoring it. Make
the dummy arguments assumed shape and you won't see that message. If you
are passing array sections (as you say that you are), you really wanty
the dummy arguments to be assumed shape unless you thoroughly understand
what is going on enough to know otherwise.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Dieter Britz

2006-10-02, 4:04 am

Dieter Britz

2006-10-02, 8:03 am

Les

2006-10-02, 8:03 am

"Dieter Britz" <britz@chem.au.dk> wrote in message
news:efqvit$v0l$1@news.net.uni-c.dk...
> Dieter Britz wrote:
>
>
> Yet another question: is there a way of finding out, within
> a Fortran program (Intel compiler 90/95) how much memory
> I am using, at any given point in the program? And is there
> a Linux command to tell me how much I am allowed? I use Suse
> 10.1.
> --
> Dieter Britz, Kemisk Institut, Aarhus Universitet

Not sure about Linux but on Windows we use the following :

type(T_MEMORYSTATUS) lpMstMemStat
call GlobalMemoryStatus(lpMstMemStat)

Les

Brooks Moses

2006-10-02, 7:03 pm

Dieter Britz wrote:
> However: in the bad old days there was virtual memory, because
> memory was rather restricted, but there was more space on
> disks. These days memory is pretty big, but not big enough
> in this case (I have just under 1 Gb), but there are about
> 30 Gb on the HD. Is there an option in the Intel Fortran
> compiler, that lets me use virtual memory, also for the
> stack?

Virtual memory is handled by the operating system; to a program, there
is no difference (other than latency) between virtual memory and real
memory. Or, at least, there shouldn't be.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Dieter Britz

2006-10-03, 8:12 am

Brooks Moses wrote:

> Dieter Britz wrote:
>
> Virtual memory is handled by the operating system; to a program, there
> is no difference (other than latency) between virtual memory and real
> memory. Or, at least, there shouldn't be.

But this seems not to be the case with the stack, which
must be expanded if it is too small. I am sure it is not
unloaded onto the hard disk if it threatens overflow.
--
Dieter Britz, Kemisk Institut, Aarhus Universitet

Brooks Moses

2006-10-03, 8:12 am

Dieter Britz wrote:
> Brooks Moses wrote:
>
> But this seems not to be the case with the stack, which
> must be expanded if it is too small. I am sure it is not
> unloaded onto the hard disk if it threatens overflow.

You're confusing two completely different types of overflow.

First, there's the physical memory on the system. If the stack space of
a program takes up more physical memory than is available, the operating
system offloads things into virtual memory on disk, assuming enough
virtual memory is available. This is no different from any other sort
of memory, and I assure you that you can start a program with 32MB of
stack space on a computer with 128MB of RAM that has 124MB already
occupied, and _something_ will get offloaded into virtual memory.

Second, there's the stack space allocated to a program. For what I
think are mostly historical reasons, operating systems traditionally
limit the stack space of a program to a small piece of memory. The
reason for this limit is that using too much stack is considered to be a
sign of a program that's not working correctly. Thus, while it would be
quite simple to fix the problem by just letting the program use more of
the available memory on the system, the operating system doesn't do
that, because the whole point of limiting the stack space is to throw an
error if it overflows! An overflow of stack space is _not_ a case of
using up all the memory actually available.

Think of it as equivalent to disk quota. The stack space is a quota,
and the program is going over quota. The disk still has plenty of
space; the solution is to increase the quota, not to increase the size
of the disk.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Sponsored Links