MKL calling TerminateProcess in every function call

[David_M_23]

Hi,

I'm trying to use the MKL functions from Embarcadero C++ Builder (ex-Borland C++), via linking with the single mkl_rt.dll file.  I am finding that every MKL method I call results in a call to TerminateProcess from within the MKL.  My guess is that this indicates an error condition of some sort in the MKL itself (alignment?  FPU word?) but nothing is printed to the debug console, and the app just terminates.

Searching on this forum and elsewhere for this gave no results.

Has anyone seen this before, or do you know what might cause a call to TerminateProcess from within the MKL library?

Further details are in the Stack Overflow question (copy/pasting here feels like spam.)  http://stackoverflow.com/questions/19728499/intel-mkl-functions-calling-terminateprocess-internally

One possible cause is that the .lib files are COFF format only, unfortunately, so I am generating an OMF library straight from the DLL via the implib tool.  If there is an error in this or it's linking to, say, the stdcall version instead of the cdecl version, that would cause problems.  However, I tried dynamically loading the methods via LoadLibrary and GetProcAddress and the same thing happened, so I suspect something else is going on.  I have also tried linking to some of the other libs suggested by the link line advisor for both dynamic and static linking (eg, mkl_intel_c_dll.lib mkl_core_dll.lib mkl_sequential_dll.lib) but converting these from COFF to OMF has given very mixed results and I haven't successfully linked that way yet. I have no reason to think it either would or would not make a difference, either.

Cheers,

David

[Zhang_Z_Intel]

David,

Pleae note that Borland C++ or Embarcadero C++ Builder is not among the compilers that MKL officially support. There might be many problems when using a legacy compiler to build MKL programs. Please see a lengthy discussion in this thread: http://software.intel.com/en-us/forums/topic/390963. Hope you can find some information there to help you work around the problem.

[David_M_23]

Thanks Zheng.  I did see Embarcadero C++ Builder is not among the compiler you officially support - but theoretically I'm just linking against a DLL, or dynamically calling a function from a DLL.  The compiler should, hopefully, not greatly matter.

The discussion you linked to is about using Borland C++ 5, which is from 1996, and the problem was incompatible type declarations in header files.  I'm trying to use BCB 2010 - from only a couple of years ago, so not legacy at all - and the problem doesn't seem to be with the header files since I can build fine.  It's a runtime error.

Does the MKL have a design where, if it detects errors, it calls TerminateProcess?  If so, then perhaps through that design I can narrow down what error is occurring.  Any insight into causes inside the MKL would be very useful, since that appears at the moment to be where the problem is.

[Zhang_Z_Intel]

David,

If you think compiler should not matter, then please try to build your code with one of the supported compilers, for example, MS Visual Studio or GCC. If the problem persists then send us a small test code.Thanks!

[David_M_23]

I will.  (And I only said "hopefully" not matter.)  But I would still like to know if there are error conditions that the MKL calls TerminateProcess in response to.  Knowing that would help diagnose the issue, or at least narrow down where I should look.

I mean, there must be a cause.  The MKL is calling TerminateProcess, that's known.  The question is why; ie, if the response is that the MKL calls TerminateProcess, then what are the conditions which can lead to that happening?

[Zhang_Z_Intel]

Dave,

I took a look at your original posting on stackoverflow. I did not see anything indicating that 'TerminateProcess' was called by an MKL function. The process was terminated right after mkl_rt.dll was loaded. But this does not mean it was MKL that terminated the process. As far as I know, MKL does not call 'TerminateProcess'. An MKL function returns an error code if it encounters an error during execution.

By the way, I double checked the 2D FFT example you mentioned. It worked fine for me. I built it on my Win 8 laptop using Visual Studio 2010.

[David_M_23]

Hi Zhang,

I took a look at your original posting on stackoverflow. I did not see anything indicating that 'TerminateProcess' was called by an MKL function. The process was terminated right after mkl_rt.dll was loaded. But this does not mean it was MKL that terminated the process.

Thankyou for looking at the original post.

I am puzzled that you didn't see anything indicating TerminateProcess was called by a MKL function, because I tried to be quite clear about that in both the SO post and here in this forum.

The process was not terminated after loading mkl_rt.dll.  The process was terminated inside the first MKL function it calls, which can be long after the DLL is loaded.  TerminateProcess is called by the MKL to the best of my ability to determine, and I know this because I stepped through the MKL assembly and watched it being called. At no point did the execution appear to step out of the MKL into, say, the Embarcadero RTL or my own code, nor does the call stack reflect any other code.  Instead, TerminateProcess was called from inside the MKL mkl_rt.dll.

I could be wrong, for sure!  But I've watched it happen dozens of times, and at the moment I'm certain (as much as one is ever certain of this knd of thing :)) of what I wrote in the SO post and here.

As far as I know, MKL does not call 'TerminateProcess'. An MKL function returns an error code if it encounters an error during execution.

That addresses my question - thankyou :)  It is puzzling, because as I said I have watched the MKL do so.  Is it possible that the Intel compiler / portions of the Intel RTL built into the DLL by the Intel compiler add code that does this?

I can see that if it works with the Intel and MS compilers then the problem is caused by using the Embarcadero compiler, or an incompatibility somewhere.  Yet without knowing what conditions can cause the library to call TP it's hard for me to narrow down what this is, and that's what I would like to do - to find out the cause.  The compiler is usually quite reliable with something as basic as a cdecl function in a library or DLL.  My suspicion is there's something else going on, more complex / deeper (my current guesses being function calling, though cdecl should be pretty basic; stack alignment; or RTL incompatibilities of some complex sort. But if the MKL can detect an error in order to terminate, even if it's a fatal error and it has to terminate, knowing what errors it can detect would be useful.)

Cheers,

David

[Zhang_Z_Intel]

David,

Please do try a different compiler to build the same code in your environment. This helps us to determin if it is indeed an issue only for ECB, or something else.

Thanks.

[neil_b_1]

Here is a working theory about TerminateProcess.  TerminateProcess is not called in MKL code.  There are situations were MKL might violate a CPU restriction (address, register, stack), and then jump to TerminateProcess.  Debuggers would roll back up the stack and show the TerminateProcess as a part of now-closed-program.

MKL is likely not at fault, but using incorrect MKL files or good files on an incorrect/malfunctioning CPU could be a problem.

Revised Jan 5 2016: My theory about incorrect/malfunctioning CPU was not supported during further investigation.  The MKL required different files to support the different hardware.  Using the correct libiomp5md.dll file is especially important.  A coworker says that is where the TerminateProcess originates (when the hardware or DLLs are correctly matched),