Segmentation fault

[jirina]

I am getting a segmentation fault in my program. When I use the debugger (idb), the program stops at at the first line of the subroutine find_binary_file_record which is called like this:

[cpp]write(name,'(a,i2.2)' 'Transformer ', i
call find_binary_file_record ( 11, name, value, .true., new_value )

subroutine find_binary_file_record ( code, name, value, check_names, new_value )[/cpp]

with

[cpp]integer*4 code
character*25 name
real*8 value
logical*4 check_names, new_value[/cpp]

in both the calling and the called subroutine if applicable.

The segmentation fault occurs in both release and debug version. The debug version is compiled using following options:

[cpp]ifort -debug -g -fixed -extend_source 132 -openmp -fpscomp general -warn declarations -assume byterecl -align all -heap-arrays -static-intel -threads *.for -o myApp.out[/cpp]

Based on the discussion in this thread, I tried adding following options:

[cpp]-fp-stack-check -check all -traceback -gen-interfaces -warn interfaces[/cpp]

However, the segmentation error is still occuring.

I made sure that the stack size is unlimited by setting it so (ulimit -s unlimited) and I am using -heap-arrays also because of OpenMP stuff in my program.

I have already mentioned this problem in this thread and it helped to increase the stack size limit. Since that, the program has been extended and the segmentation fault is back again.

I tried to read another thread on the stack usage and the segmentation fault, but I am not sure if the Linux note mentioning the stack size in various 32bit Linux distributions applies to my case. I use Fedora 10.

[jirina]

It seems that the problem was somewhere else. There were two arrays delared in the subroutine find_binary_file_record:

[cpp]subroutine find_binary_file_record ( code, name, value, check_names, new_value )
...
integer*4 MAX_CHANGES
parameter ( MAX_CHANGES=1000000 )
real*8 change_time(MAX_CHANGES), change_value(MAX_CHANGES)
...[/cpp]

It helped to change the above mentioned to

[cpp]real*8, allocatable :: change_time(:), change_value(:)
allocate ( change_time(MAX_CHANGES), change_value(MAX_CHANGES), stat=errNo )[/cpp]

[Xiaoping_D_Intel]

Moving to allocatable array resolving the error shows that the problem is still related to the stack. Is the subroutine called from inside a parallel region? Maybe you can have a try to set OpenMP runtime environment variable "KMP_STACKSIZE" to larger size like "32000000" (32m).

[jirina]

No, the subroutine is not called from a parallel region.

I went back to what was causing problems before and I ran some tests:

'ulimit -s' in the shell yields 10240 and running my program triggers the segmentation fault. I tried to include following piece of code in my application:

[cpp]integer*4 status
status = system('ulimit -s unlimited')
write(*,'(a,i3)') ' ulimit status: ', status[/cpp]

When I run my program, the status is 0, the segmentation fault occurs and 'ulimit -s' yields 10240 again. Specifying 'ulimit -s unlimited' directly in the shell resolves the problem, but I wanted my program to do this automatically. Is there any way to do it? Why does my code from above not work as expected?

I would also like to ask how to set KMP_STACKSIZE. I found in help that some functions can be called or that 'export KMP_STACKSIZE=value' can be used, but it did not work. I tried typing 'export KMP_STACKSIZE=100000000' in the shell and run my program immediately after that, but I got the segmentation fault again.

Also, I discovered that the sequence of commands 'ulimit -s unlimited', 'ulimit -s 10240' and 'ulimit -s unlimited' produces an error 'bash: ulimit: stack size: cannot modify limit: Operation not permitted'. This might be of no importance; it it just a side effect of my tests.

[TimP]

kmp stacksize sets thread stack limit. If your problem is not associated with a parallel region, KMP_STACKSIZE should not have an influence.
Depending on the context, the maximum ulimit allowed to a user may be limited by the value set as root.

[jirina]

I can set the stack size limit to 'unlimited' without having to do it as root. I just wondered if there is any way to do it from within my program.

[Kevin_D_Intel]

Yes. Ron provided a method in the earlier thread (here).