Xerbla and CBLAS/BLAS

[Mario_K_]

Hello,

I have a problem using xerbla and cblas/blas functions. The following code ends up with a segmentation fault:

#include "mkl.h"
#include <iostream>

void XERBLA(const char * Name, const int * Num, const int Len){
  std::cout << "XERBLA CALLED!" << Name << ": " << *Num << ": " << Len;
}

int main(int argc, char** argv){
  
  float a = 3.0f;
  
  int length = 1;
  int increment = 1;
  float* NullPointer = nullptr;

  /*VML*/
  vsSub(length, NullPointer, &a, &a);
  /*BLAS*/
  SCOPY(&length, NullPointer, &increment, &a, &increment);
  /*CBLAS*/
  cblas_scopy(length, NullPointer, increment, &a, increment);

  return 0;
}

This xerbla function was successfully tested with VML but for CBLAS/BLAS it is not called in the code above. Is it possible to catch invalid length/increments or nullpointer in CBLAS/BLAS?

Thank you very much,

Mario

[mecej4]

Please read the documentation for mkl_set_xerbla().

[Murat_G_Intel]

Hi Mario,

None of the BLAS functions check the input matrices/vectors for NULL pointers. Reference NETLIB implementation does not check for NULL pointers neither. It is assumed that the BLAS functions are called with valid pointers. In addition, XERBLA function is not called for the BLAS Level1 functions including SCOPY. Again, consistent with the reference implementation, SCOPY returns without computation if N<=0, and all incx/incy integer values are valid input arguments to SCOPY.

Thank you,

Efe

[mecej4]

Much of the BLAS/Lapack code was developed in the 1970s and '80s, and was written in Fortran 77. There is no such thing as a null pointer in Fortran 77. In fact, there were no pointers of any kind in standard Fortran 77. Only a bug in the compiler could cause a null pointer to be passed as an argument.

Most of the time, when you call a BLAS/Lapack routine from C, C++, C#, Fortran 9x, etc., you go through a wrapper routine that translates/maps the call in one of those languages into the equivalent Fortran 77 call. Bugs in the wrapper routines, which are probably written in C, can cause a null or an invalid pointer to be passed, and you have to detect and trap those pointers within the wrapper routines, before calling the Fortran routines. Once control reaches the Fortran 77 routine, it is too late to check for null pointers, etc., and you are probably going to see mysterious error messages, if any, before a crash.

Of course, everything could be rewritten in C, but there are many reasons why that is not feasible or worthwhile.

[TimP]

The cblas wrapper is likely to be simply a compilation of the open source.  If you want to add some more checking for NULL pointers or valid strides there, you might take a crack at it.  As Efe and Sham said, the core BLAS is a direct work-alike copy of the open source Fortran 77, regardless of the final implementation dialect.  As they said, there isn't a way to test strides accurately, but a case such as length*increment > addressable number of elements would be a clear cause for failure.  If you had a way to discover the valid address range for your user application, you could report invalid addresses.

The BLAS source misses a few odd checks; for example it's not thorough about checking for 0 lengths.   As far as I know, MKL is bug-compatible with the netlib source in such cases.

[Mario_K_]

Thank you very much for the helpful comments.

I thought that xerbla is only used for parameter checking (as in VML). It seems that I have to write own wrappers including parameter checking for my used CBLAS functions.

[mecej4]

Mario K. wrote:

I thought that xerbla is only used for parameter checking (as in VML).

MKL has many progenitors, so it has multiple personalities. The focus is more on speed on multiple cores/threads, not so much on error checking.

It seems that I have to write own wrappers including parameter checking for my used CBLAS functions.

That can be a big effort if you want to cover all the CBLAS functions. Secondly, extensive checking can lower execution speed.

Here is an alternative: Obtain the Fortran source for the BLAS, and build a library out of it with subscript checks, etc., enabled when compiling. Use this Debug BLAS Library to locate errors in your code that are attributable to mistakes in arguments to CBLAS routines, and then replace this library with MKL for production runs of your program.