MKL error handler

[Peter_A_1]

I have an MKL  routine (getrfl) that is crashing with an erro mesage that is too fast to read -  I want to see it and intecept it.  As I am building DLLs it is esential that I, at bthe very least, suppress the screen output.  I tried adding an empty xerbla routine  in my VS2008 build but it did  seem to get called (I tried  in the debugger)

 I use  IVF 11.0.066 adn MKL10.05.025.Thanks.

[Gennady_F_Intel]

Peter, can you give us the example of this failure to check the problem with the latest version? Several versions of MKL have been released since 10.0 you are using and several run-time issues with that routine were identified and fixed.

[Peter_A_1]

Genaddy In a large program call getrf(M,indx,info) is causing a crash. But, as the code is pretty well tested I suspect there is something wrong with the data or indeed the call (from a customers Pascal!). But this has prompted me to do what I should have done long ago: Make sure that, where possible, I control the error handling. Hence my first try, adding subroutine xerbla (srname, info) character*(*) srname !Name of subprogram that called xerbla integer*4 info !Position of the invalid parameter in the parameter list return !Return to the calling subprogram end So my questions are: 1. can I easily trap (most/many) errors and if so how? 2. are there errors that (like this one) that are not trappable - i.e. should I upgrade to a new Fortran hence MKL? As I said, the error flashes by too fast to see. Thanks Peter

[mecej4]

This is why your ersatz XERBLA did not get called: It is in the LAPACK and BLAS routines that invocations of XERBLA originate. If, as is most common, you use the standard MKL DLLs rather than the static libraries, the Intel-supplied XERBLA routine is already in the DLL, so references to XERBLA from the LAPACK/BLAS routines are directed to that XERBLA regardless of any XERBLA version that you provide in your code. See this previous thread: http://software.intel.com/en-us/forums/topic/289583 The MKL documentation describes how to build a custom DLL. You may build such a DLL and incorporate your own XERBLA; for example: nmake ia32 interface=stdcall export=my_func_list.txt name=mkl_small xerbla=my_xerbla.obj

[Peter_A_1]

Hi Mecej4 Thanks, this is as I feared. This seems hard work just to get an error message. (1) is this my only option? (2) I have written this XERBLA. I am hoping it will write the error message to a file and also to prevent /delay the crash. subroutine my_xerbla (srname, info) character*(*) srname !Name of subprogram that called xerbla integer*4 info !Position of the invalid parameter in the parameter list integer*4 iunit iunit=99 OPEN(UNIT=iunit, FILE='MKL_Error.log', STATUS='unknown', IOSTAT=ie) WRITE (iunit,'(A,i4)') 'srnme='//srname//' arg=',info 1000 FORMAT(A,I4) CLOSE (unit=iunit) return !Return to the calling subprogram end (3) Any tips on either how to access the required nmake, or else make the DLL in MSVS2008 (4) it would be "tidy" is the debugger could see the xerbla (but that not seem trivial) Thanks

[mecej4]

If you use the statically linked MKL libraries, you may use your custom XERBLA simply by listing the name of the object file or library file containing it before the static MKL libraries when doing the linking of your application or DLL. If you use many MKL functions, however, this approach may produce a bulky EXE file. The procedure to build a custom DLL is described in the section Building Custom Dynamic-link Libraries in the MKL User Guide. Re the wish "it would be "tidy" is the debugger could see the xerbla": The debugger could see the XERBLA entry point if the DLL contains it as a symbol, but that would be the standard Intel XERBLA rather than the one you want to use in its place.

[Peter_A_1]

I only use a few MKL functions - though I am unclear why this effect the size of the exe. Can you please clarify the crucial details: 1. if I am MSVS (2008) how do I ensure the correct link order 2. Do I then need a new name (e.g. myxerbla) It looked like MKL User Guide was more command (nmake) based. Thanks