-openmp flag causing segmentation fault

-openmp flag causing segmentation fault

intel@hellary.co.uk's picture
intel@hellary.co.uk
Mon, 08/09/2010 - 20:12

Hi all, I'm about to have a go at parallelising a program that I use. Before getting into it though, I did a quick compile of it with the -openmp flag on (with no modifications to my code whatsoever i.e. no openmp includes and no pragma omp directives). Shortly after beginning to run it crashes out with a segmentation fault. Using traceback and debug all flags don't give me any indication of what's going wrong. Any ideas on how to track down the problem? My compile flags are -openmp -traceback -debug all. I usually compile my code with just -m64 -fast. ulimit is set to unlimited I'm running OS X 10.6.4 with an Intel i7 processor and I'm using ifort version 11.1.080.

RSS Top
4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Kevin Davis (Intel)'s picture
Kevin Davis (Intel)
Tue, 08/10/2010 - 01:44

First, check your Xcode version to ensure you are not seeing effects of the incompatibility between the 11.1 compiler and newer "ld" linker bundled in Xcode 3.2.2 (and later). See this sticky post for details.

Next, perhaps the tips discussed in the knowledge base article about Determining SIGSEGV errors may help.

You should add -save-temps to your debug compilation.

Top
intel@hellary.co.uk's picture
intel@hellary.co.uk
Tue, 08/10/2010 - 06:18

Would just having Xcode installed cause issues? I have it installed but I don't actually use it, I just use a text editor and the terminal. I added the -use-asm flag that they mention though and it didn't make a difference. Nor did the -save-temps part. I've had a look through the SIGSEGV error guide and have added all of the flags to help track them down: -openmp -traceback -debug all -save-temps -use-asm -g -check bounds -fp-stack-check -gen-interfaces -warn interfaces -check arg_temp_created Still no joy. I'll need to go through my code piece by piece and see if there's anything that I've done that would cause it to mess up. Back to the world of debugging with write (*,*) statements!! I do find it a bit odd that just adding the -openmp option messes it up. I've done countless runs with this (simulation) code that can last up to a week and haven't had any problems without the -openmp flag.

Top
Kevin Davis (Intel)'s picture
Kevin Davis (Intel)
Tue, 08/10/2010 - 08:40

The GNU C/C++ development environment which our compiler uses is bundled with the Xcode package. The use of this GNU environment is not tied to using the actual Xcode GUI itself.

-save-temps isn't intended to address the segV. It saves the intermediate object files which on the Mac OS contain the debug symbols needed for debugging and symbolizing the traceback.

-openmp implies -automatic which places local variables on the stack. If you have only specified the -openmp option but have not added any OpenMP directives to your code then you may have an uninitialized variable in the code which is now on the stack and whose initial value is contributing to the segV.

If this is just a stack size issue you can refer to the URL to a pdf in this earlier post for a nice discussion on how to go beyond the ulimit setting for increasing stack space on Mac OS X.

You can load and start execution of your debug build under the debugger and see if the 'bt' or 'where' commands offer any location information where the segV occurs. You might try this with both idb and gdb.

Top

Login to leave a comment.