topic Re: Linux app goes to sleep (permanently) inside __kmp_suspend in Intel® oneAPI Math Kernel Library

Linux app goes to sleep (permanently) inside __kmp_suspend

Intel_C_Intel — Tue, 28 Mar 2006 05:13:41 GMT

Hello,

I'm building and running an application on a 32-bit RedHat Linux 3, kernel 2.4.21-4.ELsmp, glibc 2.3.2, dual-Xeon machine. I build it with the Intel C/C++ compiler for Linux, version 8.1. The application uses MKL 7.2.1 libraries (BLAS & Lapack routines.)

It was working fine until recently when I began linking in a new shared library, developed at a different site within my company, which also uses MKL. Now when I execute my application, I find that it gets hung up inside (what I think are) OpenMP routines. If I attach to the running app with gdb and do "where", it says

#0 0xb75ebc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0xb608c1ee in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/libpthread.so.0
#2 0xb68a5af5 in __kmp_suspend ()
from /400gb1/bracken/bin/libmynewlibrary.so
#3 0x00000008 in ?? ()
#4 0x08306104 in ?? ()
#5 0xb68a66a4 in __kmp_wait_sleep ()
from /400gb1/bracken/bin/libmynewlibrary.so
#6 0x00000000 in ?? ()

What could cause a problem like this?

Thanks,

--Eric

P.S. Typical command line for compiling object files:

icpc -O2 -mp -pthread -cxxlib-icc -D_FILE_OFFSET_BITS=64 -fpic -c myfile.cpp

Typical link line:

icpc -o myprog.exe -pthread -cxxlib-icc -L/path/to/MKL_V7.2.1/linux/ia32 -lmkl_lapack64 -lmkl_lapack32 -lmkl -lguide [lots of object files and libraries]

Re: Linux app goes to sleep (permanently) inside __kmp_suspend

Chao_Y_Intel — Mon, 03 Apr 2006 20:05:09 GMT

Hi,

If you set MKL_SERIAL=YES or Set OMP_NUM_THREADS=1, can this problem be removed?

Best,

Chao

Re: Linux app goes to sleep (permanently) inside __kmp_suspend

Intel_C_Intel — Tue, 04 Apr 2006 00:05:42 GMT

Hi Chao,

Setting OMP_NUM_THREADS=1 has no effect. Setting MKL_SERIAL=yes seems to work (the application successfully completes.)

Of course, disabling multithreading is not desirable for performance reasons...

One other clue: The hang occurs when we call DGETRF. Inside the code we are calling omp_set_num_threads() fairly early on. If we remove this call, then it does not hang.

Thanks,

--Eric