segmentation fault help needed

[Sandhu__Nicky]

I am porting a legacy fortran and C program from windows to linux. I was able to compile and link to get an executable but now the run fails with segmentation fault. 

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC        Routine            Line        Source
hydro              0887AE70  Unknown               Unknown  Unknown
hydro              08099AD7  dsm2_init_                176  dsm2_init.f
hydro              08064EA1  MAIN__                    151  fourpt.f
hydro              08064ABA  Unknown               Unknown  Unknown

The failing call is getpid function from module use ifort. However when run with LD_DEBUG=all it complains about an unreferenced  symbol "scalable_malloc" right around the time it fails (see further below). Any help on how to tackle this would be great. Thanks

56755:     symbol=scalable_malloc;  lookup in file=../../bin/hydro [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/mkl/lib/ia32_lin/libmkl_intel.so [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/mkl/lib/ia32_lin/libmkl_intel_thread.so [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/mkl/lib/ia32_lin/libmkl_core.so [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/compiler/lib/ia32_lin/libiomp5.so [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/compiler/lib/ia32_lin/libirng.so [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/compiler/lib/ia32_lin/libcilkrts.so.5 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/libstdc++.so.6 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/libm.so.6 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/libpthread.so.0 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/libdl.so.2 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/libc.so.6 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/libgcc_s.so.1 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/lib/ld-linux.so.2 [0]
     56755:     symbol=scalable_malloc;  lookup in file=/opt/intel/parallel_studio_2019/compilers_and_libraries_2019.0.117/linux/compiler/lib/ia32_lin/libintlc.so.5 [0]
     56755:     ../../bin/hydro: error: symbol lookup error: undefined symbol: scalable_malloc (fatal)
     56755:
 

[Juergen_R_R]

The ifort librares are 32bit libraries. Are you sure you want to have 32bit libraries?

[Sandhu__Nicky]

Yes, the code was compiled and running with 32 bit on Windows using ifort and icc. I want to port it as 32 bit and test before attempting to migrate to 64 bit.

[jimdempseyatthecove]

scalable_malloc is part of TBB (Threading Building Blocks). The TBB scalable allocator was added to OpenMP (4.0).

Try adding the TBB libraries.

Also note that your link is loading

MKL + OpenMP + Cilk

It is unusual to see OpenMP + Cilk in an application.

Does your application really contain multiple different threading paradigms?

OpenMP uses the TBB scalable allocator and possibly a sub-set of its task manager, but is not build on top of TBB. IOW OpenMP uses a thread pool designed for OpenMP and not a thread pool as used by TBB (same with Cilk). While an application can be built using multiple thread pool designs, this typically results in oversubscription of threads.

Jim Dempsey

[Sandhu__Nicky]

Hi Jim,

 I added the TBB libraries with no effect.

I was able to write a small program that failed and reducing the libraries one by one I was able to identify an old (from 80's) library that was causing the problem. 

Turns out that library defines its own getpid function in C that was being linked in by the compiler with no warnings and possibly overrode the system (ifport) provided version causing segmentation fault. 

Thanks for all your help.

[jimdempseyatthecove]

Good detective work. getpid would be O/S dependent. From the 80's predates Linux and was likely an old Unix variant.

Jim Dempsey