double precision ifort segmentation fault on run

[prozacula]

Hello,

I am a sysadmin, not a fortran programmer, but one of my associates is trying to run a very simple program, which segfaults at runtime. here is the program:

-----------
program main
integer idim
idim=150
call stupid_test(idim)
end

subroutine stupid_test(Idim1)
double precision :: xddd(Idim1*Idim1*10*10)
write (*,*) 'THIS IS SAD'
return
end
-----------

when compiled and run it only returns 'Segmentation Fault'

when run with strace, I get this at the end (I don't really know what it means, but in reading the other forum questions, I saw that it might be nice to include this info):

...
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "177ELF111���������3�3�1���@Z1�00"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1334740, ...}) = 0
old_mmap(NULL, 1340908, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40094000
old_mmap(0x401d6000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x142000) = 0x401d6000
old_mmap(0x401d9000, 9708, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401d9000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401dc000
mprotect(0x4007d000, 20480, PROT_READ|PROT_WRITE) = 0
mprotect(0x4007d000, 20480, PROT_READ|PROT_EXEC) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0x401dc080, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x40018000, 110712) = 0
set_tid_address(0x401dc0c8) = 27656
rt_sigaction(SIGRTMIN, {0x40088650, [], SA_RESTORER|SA_SIGINFO, 0x4008f210}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0) = 0x80c6a5c
brk(0x80e7a5c) = 0x80e7a5c
brk(0) = 0x80e7a5c
brk(0x80e8000) = 0x80e8000
rt_sigaction(SIGFPE, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK|SA_SIGINFO, 0x4008f210}, NULL, 8) = 0
rt_sigaction(SIGILL, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK|SA_SIGINFO, 0x4008f210}, NULL, 8) = 0
rt_sigaction(SIGSEGV, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK|SA_SIGINFO, 0x4008f210}, NULL, 8) = 0
rt_sigaction(SIGABRT, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK, 0x4008f218}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK, 0x4008f218}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK, 0x4008f218}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804a2a0, [], SA_RESTORER|SA_RESTART|SA_NOMASK, 0x4008f218}, {SIG_DFL}, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

any idea why this is? Is this user using the double precision xddd() routine incorrectly?

Thanks,

Jason

ps: uname -a:
Linux typhoon.ices.utexas.edu 2.4.25-9mdksmp #1 SMP Thu Sep 23 14:41:57 MDT 2004 i686 unknown unknown GNU/Linux

intel version:

Version 8.0 Build 20040716Z Package ID: l_fc_pc_8.0.046_pe050.1

[TimP]

This Fortran syntax is a way of creating a dynamic array, similar to a C Variable Length Array. Unfortunately, there is no error checking available, in case you are exceeding the available heap or stack space, as the case might be. It looks like you are trying to allocate over 1.7GB. I won't presume to tell you how much should be available on your system, or what shell option you would set to increase limits.

[prozacula]

that doesn't make any sense. Why would such a small, stupid program need 1.7G of memory? THis machine has 4 G anyways, but that is beside the point. I don't understand how the double precision::xddd() call, which just multipies 150x150x10x10 would need that much memory, or would segfault

Message Edited by prozacula on 10-15-2004 04:12 PM

[Intel_C_Intel]

Dear Customer,

This stupid program needsa lot ofmemory because it demandsa lot of memory at thesecond line in the subroutine. Increasing the stack size will resolve your problem.

ifort /nologo /F64000000 stup.f90
./stup.exe
THIS IS SAD

Aart Bik
http://www.aartbik.com

Message Edited by abik on 10-15-2004 05:05 PM

[prozacula]

Hello,

I really appreciate the fast response. I do not know enough about fortran, memory allocation and this new compiler version, but here is the response I got from the user (I am going to have him sign up here, because I am getting tired of passing messages back and forth - I am not an applications specialist, just a sysadmin):

+++++++++++++
Jason, this is a serious problem, and I am NOT
satisfield AT ALL with this answer. They are making
several mistakes (unless I miss something). Let's make
the numbers:

A double precision number has 8 bytes.

Idim=150, so Idim*Idim*10*10 = 150*150*10*10=
2250000. So 2250000 * 8 bytes = 18 million bytes =
18 Mega byte = 18 Mb, which is different from 1.7 Gb.

Of course we have 18 Mb. Indeed, if you define an
allocatable array, and then you allocate it
dinaymically it works (even with Idim over 800).
Furthermore, this program WORKS in the same computer
with PGF90 (again, even with Idim over 800).

So please, let them know (if you want by
forwarding this email). To response 1, that I believe
he made a mistake in the multiplication. And to
response 2:

Even if a compilation flag would make it work, I
would be quite unsatisfied because I would have to
know the memory usage before hand during compilation.
Especially, when we are talking about such low memory
requirements (18 Mb).

Again, I insist. THE SAME PROGRAM WORKS IN THE
SAME COMPUTER WITH PGF90, EVEN SELECTING Idim=800. SO
THE PROBLEM IS EITHER WITH THE INSTALLATION OR WITH
THE COMPILER, NOT WITH MY PROGRAM.
++++++++++++++

I would like to add, once again, that I don't know enough about what is going on, but any help would be appreciated.

Message Edited by prozacula on 10-16-2004 01:16 PM

[Intel_C_Intel]

Dear Jason,

I noticed the error inTim's earlier calculation too, but I tried to let it pass :-). To be even more accurate, this program requires about 17.2MB of stack space, unfortunately still more than is allocated by default (making the /F switch necessary). I dont know how to react to all the CAPITALs..Other compilers may initially reserve more stack space or, for this particular program, may even skip the stack-based allocation altogether because the array is not used. Ultimately, any run-time environment could run out of stack space, however.

Aart

Message Edited by abik on 10-16-2004 10:10 PM

[prozacula]

>>I dont know how to react to all the CAPITALs..

some of the people I work with are a little...edgy. they like to make EMERGENCIES out of everything that ever happens, even their own mistakes and lack of knowledge sometimes! (i work at a university) :)

Is there a way he can handle this dynamically in the code without specifying the stack size while compiling? He does alot of large calculations that scale dramatically depending on the input entered. This seems to me like a problem with his technique, not the way the compiler works - I think he is upset because the portland group compilers seem to do the allocation up front on their own. Is there perhaps some flag that will accomplish this with ifort?

[Intel_C_Intel]

Dear Jason,
A simple solution that does not require initially reserving a lot of stack space is to use heap-based allocation (viz. by means of explicit allocate statements). But, ultimately, one could also run out of heap, you know :-).
Aart