Hang on exit on Macintosh threaded application using MKL 10.3

[jd_weeks]

I just upgraded to MKL 10.3 update 8 as a part of upgrading my Fortran compiler. I am running on Mac OS X 10.6.8.

Since the upgrade, the application hangs on exit if at some point I call sgels() from an application thread. That is, we allocate several threads and call sgels() from each thread. Our threads use Macintosh API's, which means we are using pthreads.

If I break into gdb when hung I see this stack trace:

#0 0x99271bd2 in swtch_pri

#1 0x992e8239 in sched_yield

#2 0x02a44250 in rml::internal::doInitialization

#3 0x02a86714 in __kmp_internal_end_atexit

#4 0x99290c0a in __cxa_finalize

#5 0x99290b14 in exit

#6 0x94195444 in ExitToShell

#7 0x011656b1 in MacIgorMain at Igor.cpp:1441

#8 0x0116e593 in main at MacMain.cpp:8

#0 0x99271bd2 in swtch_pri#1 0x992e8239 in sched_yield#2 0x02a44250 in rml::internal::doInitialization#3 0x02a86714 in __kmp_internal_end_atexit#4 0x99290c0a in __cxa_finalize#5 0x99290b14 in exit#6 0x94195444 in ExitToShell#7 0x011656b1 in MacIgorMain at Igor.cpp:1441#8 0x0116e593 in main at MacMain.cpp:8

I tried callingmkl_set_num_threads(1) before the call to sgels, but it didn't help.

Does anyone know anything about this? Seen anything like it before?

Thanks,

John Weeks

[barragan_villanueva_]

Hi,

At the first glance it's a problem in libiomp5 library.... or alsoinMacIgorMain at Igor.cpp:1441.
Could you please create a small testcase to reproduce this on our side?
Pleaseadd details on used linking line with MKL.

[jd_weeks]

Thank you, Victor. This is part of a very large and complex application. I'm not sure I even know how to create such a test case without bringing in lots of our code.

Another engineer here seems possibly to have solved the problem by explicitly closing our own threads before exit. That would solve our problem, but I'm still left puzzled by why our threads would cause a hang in MKL code.

-John Weeks

[Gennady_F_Intel]

John, in that case one thing we can recommend you to try linking your code with sequential version of MKL.

See here Linker Adviser how to do that.

[jd_weeks]

A big reason for us to use MKL is the threaded LAPACK support.

-John

[barragan_villanueva_]

John,

To use threaded MKL (which is based on OpenMPlibiomp5-library) together with your pthreads in one application it needs to have some "consensus" on run-time with running threads or so.
If it's not easy to create some reproducer, then my suggestion is to use some workaround first to find out later real problems in your application or in MKL/Iomp etc.

[Ying_H_Intel]

Oritmay easy for youto build a test case based on MKLexample code: lapacke_sgels_row.c under \examples\lapacke\source and add two pthread call to simulate yourscene?

Best Regards,
Ying