Nested do and select case loops segfault on debian linux/ifort8.0

[bourdin]

Hi,

I am having trouble running program compiled with the latest version of the fortran compiler, under debian linux testing/unstable:
Consider the following program:
Program TestSegFault

Integer :: NbE, iE, i
character(len = 17) :: str1


str1 = '12345678901234567'

Print*, 'Size of Big Loop '
Read*, NbE

Do iE = 1, NbE
Case1: Select Case (Str1)
Case ('12345678901234567')
! Print*, iE
End Select Case1
End Do
End Program TestSegFault

It compiles fine with both ifc 7.1 and ifort 8.0.
Both version run on RH 7.3, Mandrake 9.2, but the one compiled with ifort 8.0 segfaults on debian

Here is what I could get from running the program in idb:
object file name: TestSegFault
Reading symbols from TestSegFault...done.
(idb) run
1Starting program: TestSegFault
Size of Big Loop
25000
Thread received signal SEGV
for_cpstr () at unknown
(idb) backtrace
#0 0x8053ba8 in for_cpstr () in TestSegFault
#1 0x8049e9d in testsegfault () at TestSegFault.F90:14
#2 0x8049d38 in main () in TestSegFault
#3 0x400e2dc6 in /lib/libc.so.6

Also, the number of iterations before it crashes is related with the length of the string str1.
130633 when len(Str1) .LE. 16,
65316 when 17 .LE. str1 .LE. 32
43544 when str1 .GE. 32

a few version informations:
package_id l_fc_pc_8.0.046
glibc 2.3.2
kernel 2.4.21

Something perhaps relevant: Debian uses LinuxThreads, while the versions of RH and Mandrake I was able to run the code under still use posix threads.

Any idea?


Blaise

[Steven_L_Intel1]

Does the following quote from the release notes help?

Segmentation Violation with static link to libpthreads

Applications built with libpthreads.a statically linked, (libpthreads.a is used by default when -static is used), may fail with a segmentation violation on some versions of Linux when the applications use more than 2MB of stack space. This is a known limitation of Linuxthreads. If you encounter this problem, link libpthreads dynamically. As an alternative, on Red Hat Linux 9 and Red Hat Enterprise Linux 3.0, you can install the nptl-devel package and pass "-I/usr/include/nptl -L/usr/lib/nptl" on the ifort command line. This will create a statically-linked binary which will run under nptl only, but which does not have the stack size limitation.

[bourdin]

Unfortunately, it does not help...
- My test example won;t run even if dynamically linked.
- I can't link statically
fermat:~/TestSegFault> ifort -static -o TestSegFault TestSegFault.F90
/opt/intel/compiler80/lib/libifcoremt.a(for_open_proc.o)(.text+0x3929): In function `for__compute_filename':
: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/opt/intel/compiler80/lib/libifcoremt.a(for_open_proc.o)(.text+0x3a0c): In function `for__compute_filename':
: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

- nptl is not available under debian

Thanks,

Blaise

[Steven_L_Intel1]

Well, I don't know what to tell you then. Debian is not a supported distribution for Intel Fortran.

[bourdin]

Dear Lionel,

I understand that Debian is not a supported platform. However, not being the admin on the machine on which the problem occurs, I have little control on that.

At this point, the most likely reason for my example to segfault is that the stack grows beyond the 2Mb limit of debian's libc or threading system. A quick read of the thread name "Array size problems" on this forum suggests that this is not an isolated case.

Provided that this hypothesis is correct, is the fact that programs compiled with ifort use so much stack space a bug or a feature? If it is a bug, any chance that it is going to be fixed?

Thanks,

Blaise

[Steven_L_Intel1]

It is neither a "bug" nor a "feature" It is an implementation choice. It is good in some ways, not good in others. That it interacts badly with buggy pthreads implementations, and there are a lot of those, is not really the compiler's fault.

Here is text we added to the release notes for a future release - I don't know if it will help you. Note the part about not using "unlimited".

OpenMP Limitations

POSIX threaded programs that require a large stack size may not run correctly on some versions of Linux because of hard-coded stack size limits in some versions of the Linux POSIX threads libraries. These limits also apply to OpenMP programs (-openmp) and automatically generated parallel programs (-parallel) with the Intel compilers, because the Intel compilers use the POSIX threads library to implement OpenMP based and automatically generated parallelism. Threaded programs that exceed the stack space limit usually experience segmentation violations or addressing errors.

To avoid these limitations, use a version of glibc built with the FLOATING_STACKS parameter defined. For some distributions, this implies using the shared rather than the static version of the pthreads library. Then use the ulimit -s or limit stacksize command to set the maximum shell stack size to an explicit large value, in units of KBytes, (not unlimited), and also set the KMP_STACKSIZE environment variable to the needed thread stacksize in bytes. Note, in the bash shell, ulimit -s can be used to set a large maximum stack size only once. In the C shell (csh), limit stacksize , with no dash before the argument, can be used to reset the maximum stacksize repeatedly.

There are some known pthreads issues when the maximum shell stacksize is set to unlimited, which is the default value for certain recent Linux distributions. These can result in overlapping thread stacks and segmentation faults or other failures. In most cases, they can be worked around by setting the maximum shell stack size to an explicit value. Although this is not a compiler issue as such, a future update to the compiler may detect the overlapping stacks condition and abort with a warning message. It will still be necessary to reset the maximum shell stacksize appropriately in order to run the program to completion.

This solution has been tested on glibc version 2.2.4-13 for IA-32 and glibc 2.2.4-19 for Itanium Processor Family as found in the RedHat 7.2 Linux distribution. For glibc 2.2.4-13 on IA-32, the shared version of the POSIX threads library must be used, (there should not be a -static flag in the compiler .cfg file or on the command line).

[bourdin]

Dear Lionel,

---

sblionel wrote:

It is neither a "bug" nor a "feature" It is an implementation choice. It is good in some ways, not good in others. That it interacts badly with buggy pthreads implementations, and there are a lot of those, is not really the compiler's fault.

Thanks for clarifying this point. In particular, this answers my main concern, that is to know if this issue will be resolved in a later version of the compiler, or not. We will have to decide on wether to downgrade to 7.1 or use a different thread system.

Blaise

[Steven_L_Intel1]

Version 7.1 is available to those who have an active support license. But be aware that you may have problems with this too using buggy pthread implementations.

[ryofurue]

Hello all,

I'm having a similar segfault. Although I've carefully followed
this thread, I still don't understand one thing. I'd appreciate
it if you could enlighten me: Am I using the problematic thread
library? How can you tell whether you are using it or not?

I created a test case to reproduce this problem, which I submitted
as an "issue" (I haven't received an answer, yet). There,
all my source files are compiled without any options. The set of source files is self-contained; that is, no non-intrinsic
functions or procedures are called. I'm appending the main program
of the test case. The program segfaults before the first
executable statement. When I decrease the number of arrays,
the program runs correctly. Also, I have an "unlimited" stacksize.

Is the thread library the most likely cause?

Thank you,
Ryo

==============================
program geostrophy
use geo_coco3, only: init_geo_coco3, finish_geo_coco3, nx, ny, nz
implicit NONE

call init_geo_coco3
write(*,*) "nx, ny, nz = ", nx, ny, nz
call process
call finish_geo_coco3

contains

subroutine process
use numeric_kinds, only: double
real(double), dimension(nx,ny,nz):: a1, a2, a3, a4, a5, a6
write(*,*) "hello"
end subroutine process

end program geostrophy