Signal: Segmentation fault (11) with "-fast"

When I compile my code with “-g”, it works well. However when I compile the code with “-fast”, it occurs the following mistake:

[ubuntu201:05104] *** Process received signal ***
[ubuntu201:05104] Signal: Segmentation fault (11)
[ubuntu201:05104] Signal code: Address not mapped (1)
[ubuntu201:05104] Failing at address: 0x7ffd00000000
[ubuntu201:05104] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f4d27fcc390]
[ubuntu201:05104] [ 1] ./cfl3d_mpi[0x4bbff6]
[ubuntu201:05104] [ 2] ./cfl3d_mpi[0x4611eb]
[ubuntu201:05104] [ 3] ./cfl3d_mpi[0x4368aa]
[ubuntu201:05104] [ 4] ./cfl3d_mpi[0x42b2ef]
[ubuntu201:05104] [ 5] ./cfl3d_mpi[0x4061e2]
[ubuntu201:05104] [ 6] ./cfl3d_mpi[0x403086]
[ubuntu201:05104] [ 7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f4d26f98830]
[ubuntu201:05104] [ 8] ./cfl3d_mpi[0x402f79]
[ubuntu201:05104] *** End of error message ***
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.

What can I do to solve the problem?

Sounds like an optimization issue. It’s either a compiler issue where it’s misapplying an optimization or a bug in the program that only gets exposed with optimization. Hard to tell with out a reproducing example.

I usually start by first finding which section of code is causing the problem. Does the error occur if you compile with “-fast -gopt”? “-gopt” will add debug information but not disable optimizations that alter code order (like -g does). If so, run the binary through a debugger and see where the segv occurs. Because the code is optimized, it may be difficult to tell exactly why the error is occurring, but at least it will get to the right spot.

You can then add a directive to lower the opt level for this routine, or compile the one file at a lower optimization.

For details on using directives see:

In particular, the “opt” directive:

Note that in some cases, the error is not in the same section of code as the seg fault. So if lowering the opt level at this one spot does not work around the problem, you may need to do a binary search of the other files. By this I mean that you compile half of the other source with “-g” and the other half with “-fast”. If it still segvs, then replace half of the “-fast” files with “-g”. If the segv goes away, replace half of the “-g” files with “-fast”. Repeat until you find the offending file. You can then refine further by using the directive to enable or disable optimization at a routine level within the file.

In rare cases, the problem may occur in multiple files. So if the binary search does not find a particular file, the final method would be to compile all files with “-g”, then add “-fast”, one file at a time until the segv occurs. Note that file, revert back to “-g”, and then continue adding “-fast” to each additional file until all files which cause the error are found.

Another helpful tool is Valgrind (www.valgind.org), especially for finding out-of-bounds issues or other memory problems.

Now all these methods just help identify where in the code the error is coming from. Determining the actual error will take inspection of the code.

If you do suspect that this is a compiler issue, please feel free to post or send to PGI Customer Service (trs@pgroup.com) a reproducing example and we will investigate.

Hope this helps,
Mat

Hi,Mat
There is no problem with this program running on another PGI compiler version(18.4). I tried the original code(CFL3D) with PGI version(19.4) and it also occured this problem.

Ok, it’s very possibly a compiler issue. In that case, we’ll need a reproducing example to diagnose.

Can you send one to PGI Customer Service (trs@pgroup.com)?

-Mat

ok,thank you very much