running OpenMP-enabled programs: segmentation fault

running OpenMP-enabled programs: segmentation fault

[Eugéne Suter]

Hello,

I am adding OpenMP directives to a serial library I have been working
on. However, I cant get any driver program linked to the library
(dynamic linking) to execute.
The program simply segfaults as soon as it starts executing anything
in the openmp parallel code block.
After "googling" for a while, the problem seems like it might be a
lack of stack space, and there was one site that specifically gave an
example of this problem:

https://computing.llnl.gov/tutorials/openMP/exercise.html

The file "omp_bug4" will segfault when run. However, the "fix" they
provide does not work, I still get the segmentation fault (in my
project and in the example they provide).
I have tried adjusting my shell's stack limit with "ulimit -s
unlimited" and other environment variables (KMP_STACKSIZE,
GOMP_STACKSIZE, etc...) and all to no avail.

My system specs are:

Intel Core 2 Duo
1 GB ram
Slackware 12.2 (GCC 4.2.4)

I also compiled my own custom kernel,  but using Slackware's as a
template and only making minor ajustments. Is there perhaps some
specific kernel configuration that could solve this problem?

Any help is very much appreciated.

Cheers

Re: running OpenMP-enabled programs: segmentation fault

[Tim Prince]

Eugéne Suter wrote:
> snipped, as much rambling stuff as the following reply:
I hesitate to respond, as I can see reasons for Tbird to be putting you in
the spam box.  I don't see this as the place for advice on how to learn
about the stack size adjustment of a self built kernel.  If you are using
the Intel OpenMP library (with a kernel it was not intended to be used
with), that also is a responsibility you have taken on yourself which
seems off topic here.
I do use the Intel library with gomp, but avoid using its special features
or non-mainstream kernel builds.
That said, KMP_STACKSIZE adjusts the thread stack.  Intel libiomp should
start it out at 4MB (on x86_64); 2MB on a normal 32-bit kernel.  You might
want to check it, to see whether it is getting along with your kernel in
that respect.  No reasonable basic test program should run into any
difficulty with default thread stack setting, even on 32-bit Windows.
Thread stack is distinct from main program stack, which would be dealt
with by ulimit, if that fits with the shell you are using.  Am I assuming
too much to think that you would have checked ulimit to see if it
responded to your setting?
I note that the example you quote doesn't USE OMP_LIB, as it should, if
you are using a version of gfortran which has implemented the required
standard include files.  I've heard there is a plan to fix this for next
release.
If you take their example to imply that libgomp understands the same
environment variables as libiomp, that also is an indication that you have
too much faith in them and their clairvoyance.  In 2004, llnl would not
have wanted to support gomp on their system, and would not have considered
whether libgomp was planning to adopt Intel extensions.
Those examples should at least educate you about which ways you could be
requiring abnormally large thread stacks.
If you had a question specifically about gfortran, fortran@gcc.gnu.org
might be a good resource.  It's not clear that you do, however.  It would
be good to search the archives for posts which might be relevant.

Re: running OpenMP-enabled programs: segmentation fault

[Eugéne Suter]

2009/2/16 Tim Prince <TimothyPrince@sbcglobal.net>:
> Eugéne Suter wrote:
>> snipped, as much rambling stuff as the following reply:
> I hesitate to respond, as I can see reasons for Tbird to be putting you in
> the spam box.

Please feel free to do so. I probably should have mentioned that I'm
new to OpenMP and shared memory programming in general. So it was a
bit hasty of me to post one of my first problems here.

Sorry for the inconvenience.