Segmantation fault with mixed Fortran/C programs using icc/ifort 8.0

Segmantation fault with mixed Fortran/C programs using icc/ifort 8.0

Hello,

I am not certain whether this is a Fortran problem, since it occurs when mixing object files from both Fortran and C sources, therefore I apologize in advance if this is the wrong forum to post my question.

Recently I upgraded from version 7.1 to version 8.0 of the Intel Fortran and C/C++ compilers and this broke my applications. I develop a threads library in C and I use icc to compile it. In order to test my library I use version 3.0 of the OpenMP NAS Benchmarks. The benchmarks are preprocessed with a source-to-source compiler and the output is an equivalent Fortran program with calls to my library. The preprocessed benchmarks do not contain anymore the main function of the program, which is defined in the library I develop and which is responsible to call the first routine of the benchmark (new_program_main() in the following example). Therefore I need the -nofor_main option in the link stage. The process to build an application is as follows:

1) Build threads library (as a shared library) with icc (everything compiles fine. Options used are -w1 -g -c -D_REENTRANT)
2) Pass benchmark sources through the source-to-source compiler (everything compiles fine)
3) Pass output of the source-to-source compiler through ifort to create object files (everything compiles fine. Options used are -w1 -g -c -auto -stack-temps -D_REENTRANT)
4) Link object files from Step 3 with library from Step 1 using ifort (everything compiles fine. Options used are -nofor_main)

The executables are produced without any problem, but when I try to execute them they start and almost immediately give me a segmentation fault. Using gdb I found that the problem lies in the function __pthread_internal_tsd_get(). Executing the "where" command under gdb (while running the CG benchmark) gives the following results.

#0 0x4008b96d in __pthread_internal_tsd_get () from /lib/libpthread.so.0
#1 0x40139da4 in malloc () from /lib/libc.so.6
#2 0x080626b7 in for__get_vm ()
#3 0x08056dfe in for__acquire_lun ()
#4 0x08059bc2 in for_open ()
#5 0x0804a301 in new_program_main ()

Executing the application step-by-step under gdb revealed that the problem lies in the following source line of the CG benchmark:

OPEN(unit=2, file='timer.flag', status='old', iostat=fstatus)

This problem occurs only when I use version 8.0 of the Intel compilers. The applications execute without any problems with version 7.1 of the Intel compilers and with gcc.

I also tried other command line options (-O2 for example) and also removed the -D_REENTRANT option from all stages, but the problem remains.

Any ideas about what the problem could be?

Thank you in advance,

Ioannis

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The pthreads library comes from linux, so it will be quite important to specify the glibc version you use. If you can submit a reproducer to premier.intel.com, which works with 7.1 and fails with 8.0, on the same glibc, that could be valuable, and you should give it high impact rating.
Unless you have pushed over a threshold for available memory, it does look like a bug in 8.0. Even if that is the case, your use of iostat should enable you to capture a failure code rather than a segmentation fault.

I was quite certain that I would forget to give some important information :-)

I have a RedHat 9.0 system, updated with the latest glibc RPMS from the rawhide directory (when it was still available, which means before the Fedora project started). An "rpm -qa | grep glibc" gives:

glibc-2.3.2-101.1
glibc-common-2.3.2-101.1
glibc-debug-2.3.2-101.1
glibc-devel-2.3.2-101.1
glibc-headers-2.3.2-101.1
glibc-profile-2.3.2-101.1
glibc-utils-2.3.2-101.1

I think that this is not the recommended version, but version 7.1 of the compiler works just fine.

Although it will probably be quite difficult to create a test case that reproduces the problem, as I am not allowed to give away the source code of the library, I will try to come up with something.

As for the threshold of available memory, it is quite unlikely that this is the problem. When the application crashes, it uses only about 19-20MB of memory (I stopped the application with gdb exactly before it crashes and used ps).

One more question that I have is why the compiler uses pthreads in a program I didn't ask it to do so. This seems a little bit odd to me.

Thank you,

Ioannis

Red Hat 9 has been quite difficult for me and some customers, as I see serious memory leaks. This is evident in the change between top report of memory in use before and after running an application QA script. Once a significant amount of memory has leaked away, pthreads will fail for that reason. Hung processes belonging to root are left behind, but killing them doesn't recover memory.

The closest distro to red hat 9 which the Intel compiler team has undertaken to support fully is red hat EL 3.0, since red hat no longer supports 9.0.

I mention these problems only to point out some of the difficulties I have had in isolating problems with applications working for 7.1 and failing for 8.0, and the difficulties I foresee in having the compiler team correct such problems. Customers have non-repeatable problems with ifc 7.1 on rh9 as well. I expect that I will need to work with EL 3.0 shortly.

I was surprised that you didn't expect pthreads to be linked, since you are using threading.The -openmp option invokes pthreads,in applications which I am testing.

Yes, I am aware that the Intel Compilers implement OpenMPusing pthreads asthe backend threading library, but I am not using the -openmp option. The preprocessor I mentioned in the first message transforms all OpenMP directives into appropriate calls to my library. Think of it as using my library as the backend to the compiler, instead of the pthreads library. This is why I didn't expect to see any calls to the pthread library.

Anyway, I will probably switch back to version 7.1 until such issues have been resolved.

Ioannis

Please report the problem to Intel support so that it can be investigated.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today