mkl_domatcopy segfaults and/or produces incorrect results

[DavidCortes]

I am getting a segfault every time I try to use the C version of 'dmatocopy' to transpose a matrix. Calling the Fortran version doesn't lead to segfaults but (a) oftentimes produces results with incorrect signs (producing values with the right magnitude but incorrect sign); (b) returns a zeroed out matrix when the inputs are large.

Processor is a 12700H and I'm using MKL version 2023.1.0.

This particular C++ example segfaults, for example:

#include <iostream>
#include <cstddef>
using std::size_t;
extern "C" void mkl_domatcopy (char ordering, char trans, size_t rows, size_t cols, const double alpha, const double * A, size_t lda, double * B, size_t ldb);
extern "C" void mkl_domatcopy_(const char *ordering, const char *trans, size_t *rows, size_t *cols, const double *alpha, const double * A, size_t *lda, double * B, size_t *ldb);

int main()
{
double A[] = {
1., 2., 3.,
4., -5., 6.,
7., 8., -9.,
10., 11., 12.,
13., 14., 15.,
};
double B[15] = {0};
size_t nrows = 5;
size_t ncols = 3;
mkl_domatcopy('R', 'T', nrows, ncols, 1., A, ncols, B, nrows);

double one = 1.;
mkl_domatcopy_("R", "T", &nrows, &ncols, &one, A, &ncols, B, &nrows);

std::cout << "B:" << std::endl;
for (int col = 0; col < ncols; col++)
{
std::cout << "[ ";
for (int row = 0; row < nrows - 1; row++)
std::cout << B[row + col*nrows] << ", ";
std::cout << B[nrows-1 + col*nrows];
std::cout << "]" << std::endl;
}

return 0;
}

When using -fsanitize=address I get the following information:

==3684770==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000054 (pc 0x7f5250bf6c
cf bp 0x000000000005 sp 0x7ffedfc70640 T0)
==3684770==The signal is caused by a READ memory access.
==3684770==Hint: address points to the zero page.
   #0 0x7f5250bf6ccf in MKL_DOMATCOPY (/opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_int
el_lp64.so.2+0x3f6ccf)
   #1 0x55fa0a5c6771 in main /home/david/c_quicktest/dmatocopy.cpp:19
   #2 0x7f5259a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
   #3 0x7f5259a46244 in __libc_start_main_impl ../csu/libc-start.c:381
   #4 0x55fa0a5c6170 in _start (/home/david/c_quicktest/a.out+0x1170)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_intel_lp64
.so.2+0x3f6ccf) in MKL_DOMATCOPY
==3684770==ABORTING

Commeting out the line calling the C-version function in order to use the Fortran one produces the right result in this particular example, but as the inputs grow larger, the more likely it is to produce something incorrect as output.

[ShanmukhS_Intel]

Hi David,

Thanks for posting in Intel communities and sharing the code.

We could see a similar sort of output at our end. We will investigate further and will get back to you soon with an update.

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi David,

It seems there might be an issue in the arguments/ sizes/ headers given to the routine mkl_domatcopy() or being used.

Could you please refer to the below link and cross-verify if all the parameters were given correctly?

https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2023-1/mkl-omatcopy.html

In addition, We have run the example provided by Intel oneAPI and could see it performing without any issues. Hence, we would like to request you refer to the domatcopy example provided in the example folder structure below for further cross-verification and let us know if the issue persists.

"C:\Program Files (x86)\Intel\oneAPI\mkl\2023.1.0\examples\examples_core_c\c\trans\source\domatcopy.c"

Best Regards,

Shanmukh.SS

[DavidCortes]

There is still a segfault if using the same matrix and parameters from the built-in example.

From some investigation, it seems that it is necessary to include the exact MKL headers that the example uses in order for it to work, as it looks like the function signature is altered through the C preprocessor in those headers, unlike the BLAS and LAPACK functions in which the functions are actual symbols in the library that can be used in external code after declaring them with the same parameters as the header does.

This is very much a non-standard and problematic way to offer public functions for a library that aims to have C interface.

Here I've modified my example to use the matrix and parameters from the built-in MKL examples. It still crashes:
#include <iostream>
#include <cstddef>
using std::size_t;
extern "C" void mkl_domatcopy (char ordering, char trans, size_t rows, size_t cols, const double alpha, const double * A, size_t lda, double * B, size_t ldb);

int main()
{
size_t nrows = 2;
size_t ncols = 4;
double A[] = {
1., 2., 3., 4., 5.,
6., 7., 8., 9., 10.,
11., 12., 13., 14., 15.
}; /* source matrix */
double B[8] = {0};
mkl_domatcopy('R', 'T', 2, 4, 1., A, 5, B, 2);
std::cout << "done with transpose" << std::endl;

std::cout << "B:" << std::endl;
for (int col = 0; col < ncols; col++)
{
std::cout << "[ ";
for (int row = 0; row < nrows - 1; row++)
std::cout << B[row + col*nrows] << ", ";
std::cout << B[nrows-1 + col*nrows];
std::cout << "]" << std::endl;
}

return 0;
}

[ShanmukhS_Intel]

Hi David,

Seems you are missing the implementation of header MKL_TRANSPOSE from the library.

Could you please add the "#include <mkl_trans.h>" header to your code which is present under "C:\Program Files (x86)\Intel\oneAPI\mkl\2023.1.0\include" and let us know if the issue persists?

Best Regards,

Shanmukh.SS

[DavidCortes]

It is indeed missing, and purposefully so: if one is building a library that uses BLAS/LAPACK and distributes such library to users to install from source, it's unreasonable to expect library headers to be there (they aren't even included in some intel-provided distributions of MKL).

Most libraries out there offering BLAS linkage declare the function prototypes without including a header that would be tied to a particular implementation, and this works for pretty much every other function in MKL. Also works for the equivalent 'cblas_domatcopy' in OpenBLAS.

[ShanmukhS_Intel]

Hi David,

Thanks for sharing the details. We are discussing your issue internally. We will get back to you soon with an update.

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi David,

If you would like to use the current function call , please declare the function MKL_Domatcopy as below:

To use the C interface:

extern "C" void MKL_Domatcopy(char ordering, char trans, size_t rows, size_t cols, const double alpha, const double* A, size_t lda, double* B, size_t ldb) and call the function as below.

Function call:

MKL_Domatcopy('R', 'T', 2, 4, 1., A, 5, B, 2);

Alternatively to use the Fortran interface:

extern "C" void mkl_domatcopy(char* ordering, char *trans, int* rows, int* cols, const double* alpha,const double* A, int* lda, const double* B, int* ldb); and call the function as below.

Function call:

mkl_domatcopy(&ordering, &trans, &nrows, &ncols, &alpha, A, &lda, B, &ldb);

Kindly let us know if the issue persists.

Best Regards,

Shanmukh.SS

[DavidCortes]

That sort of thing would indeed work with the current version of MKL - however, I see from the header that it is a preprocessor renaming, and doesn't correspond to anything in the MKL online docs, which leads me to wonder whether it might get removed in a later version as it technically wouldn't break backwards compatibility.

Nevertheless, while this might provide a current workaround for **this** particular case, the underlying issue remains:
(a) The docs mention a function 'mkl_domatcopy', not 'MKL_Domatcopy'; (b) these functions from the docs are all supposed to be symbols following C linkage format; (c) the library is supposed to be usable without the headers.

[ShanmukhS_Intel]

Hi David,

A gentle reminder:

Has the information provided helped?

If this resolves your issue, please accept this as a solution. It would help other users with similar issues.

Best Regards,

Shanmukh.SS

[ShanmukhS_Intel]

Hi David,

Thanks for helping us improve our products! We’ve submitted the request to the concerned team, and they will consider it based on multiple factors including, but not limited to priority and criticality of the feature. 

Best Regards,
Shanmukh.SS