topic Hi Ben, in Intel® oneAPI Math Kernel Library

Crash on exit after calling MKL VML functions

Ben_V_1 — Thu, 26 Oct 2017 13:55:00 GMT

Hi,
I'm experiencing a crash on exit after calling one of MKL VML functions (declared in mkl_vml_functions.h). I'm running on OS X.

The following flow leads to the crash:

My dynamic library (let's name it 'dylib1') is loaded from an application.
dylib1 loads another dynamic library on run-time using 'dlopen()' (let's name the latter 'dylib2').
dylib2 loads an MKL customized dynamic library on load-time.
dylib2 calls an VML function (for example, 'vsLn()').
When quitting the app, 'dlclose()' is called from dylib1, in order to close dylib2.
A crash is caused by EXC_BAD_ACCESS.

Few more details:

My MKL code works on both Windows and OS X, but crash happens only under OS X.
This crash seems to happen only when calling VML functions (for example, 'vsLn()', 'vsSub()' and 'vsAdd()').
When I tried calling other MKL functions which are not declared in mkl_vml_functions.h (for example, 'cblas_copy()', "DftiCreateDescriptor' and 'MKL_Get_Version_String()') - program did not crash on exit.
Furthermore, crash seems to happen only if 'dlclose()' is called for dylib2. If I don't call 'dclose()', crash does not happen.
Customized MKL dylib was build with version 11.3.4, but I also tried to build it with version 2017.4, and crash still happens.
dylib1 is a plug-in loaded from the application. I'm not the developer of the application, and therefore I can't exactly know what it does.
I couldn't reproduce the crash with my own application, and therefore not attaching any code to this post.

I saw another report in this forum about similar crash under Linux (https://software.intel.com/en-us/node/629264), that was fixed in version 2016.2.
My guess is that my problem is also related to thread clean up.

Am I doing something wrong? or is it related to some MKL thread cleaning issue?
Please advise and let me know if I can supply further details.

Thanks a lot,
Ben

>> dylib2 loads an MKL

Gennady_F_Intel — Fri, 27 Oct 2017 06:01:32 GMT

>> dylib2 loads an MKL customized dynamic library on load-time.

Could you please to shed some light into what do you mean by that? How do you do that?

I built a custom dynamically

Ben_V_1 — Sun, 29 Oct 2017 09:33:54 GMT

I built a custom dynamically linked shared MKL library, since I need to use only some MKL functions in my code.
Customized library is built with the following command:
libuni threading=sequential export=<function list file> name=libmkl_custom

dylib2 loads libmkl_custom.dylib on load-time. This is done through linking dylib2 with the following commands:
-L<libmkl_custom.dylib path> -Wl,-rpath,<libmkl_custom.dylib path> -lmkl_custom

Hi Ben,

Jingwei_Z_Intel — Tue, 14 Nov 2017 00:49:24 GMT

Hi Ben,

Sorry for my ignorance, what is "libuni" you are talking about? Do you have a small reproducer for the problem.

Thanks,

Jingwei

Hi Jingwei,

Ben_V_1 — Mon, 27 Nov 2017 13:55:13 GMT

Hi Jingwei,
Thanks for your response.

I’ve managed to create a smaller reproducer to this issue. Code is attached to this post.
I created a customized MKL dylib with the following command:
make libuni threading=sequential export=mkl_function_list name=libmkl_custom
(this command is taken from MKL Mac OS X user guide: https://registrationcenter.intel.com/irc_nas/2690/mkl_userguide_mac.pdf).

The attached XCode project is compiled to an application, and to a dylib (let's call it dylib1). dylib1 is linked to
the customized MKL dylib.

This is the application workflow:
1. Application opens a thread, and then calls 'pthread_join()' for this thread.
2. Thread dynamically loads dylib1 (with ‘dlopen()’), and calls its 'TestFunc()' function.
3. 'TestFunc()' function calls a vml function ('vsAdd()').
4. 'TestFunc()' returns, and 'dlclose()' is called for dylib1.
5. Thread returns, and application crashes in 'pthread_join()'.

Please note that removing the call to 'vsAdd()', eliminates the crash.
Moreover, not calling ‘dlclose()’ also eliminates the crash.

Bug was reproduced on OS 10.12.6, with MKL version 2018.0.1. Both executable and dylib were compiled with LLVM 9.0.
Please see readme.txt in attached zip for more details.

Thanks for the support,
Ben

Hi Ben,

Jingwei_Z_Intel — Thu, 30 Nov 2017 16:27:16 GMT

Hi Ben,

We have found the root cause of the issue in our library. We will fix the problem in the next release.

Thanks,

Jingwei