Invalid read of size 4 in ctrmm_iutncopy_SANDYBRIDGE

[amigalemming]

I've got hard to reproduce crashes when calling ctrmm with 2x2 matrices on sandybridge. Valgrind says:

==4642== Invalid read of size 4
==4642==    at 0x797BFD1: ctrmm_iutncopy_SANDYBRIDGE (in /usr/lib/libopenblasp-r0.2.18.so)
==4642==    by 0x69E9700: ctrmm_LNUN (in /usr/lib/libopenblasp-r0.2.18.so)
==4642==    by 0x5963BBA: ctrmm_ (in /usr/lib/openblas-base/libblas.so.3)
==4642==    by 0x711075: ??? (in .../haskell/lapack/dist/build/lapack-test/lapack-test)
==4642==    by 0x42000BE147: ???
==4642==    by 0x42001FFFCF: ???
==4642==    by 0x42001FFFB7: ???
==4642==    by 0x42000BE06F: ???
==4642==    by 0x42001FFFB7: ???
==4642==  Address 0x4200200000 is in a --- anonymous segment
==4642== 
==4642== 
==4642== Process terminating with default action of signal 11 (SIGSEGV)
==4642==  Bad permissions for mapped region at address 0x4200200000
==4642==    at 0x797BFD1: ctrmm_iutncopy_SANDYBRIDGE (in /usr/lib/libopenblasp-r0.2.18.so)
==4642==    by 0x69E9700: ctrmm_LNUN (in /usr/lib/libopenblasp-r0.2.18.so)
==4642==    by 0x5963BBA: ctrmm_ (in /usr/lib/openblas-base/libblas.so.3)
==4642==    by 0x711075: ??? (in .../haskell/lapack/dist/build/lapack-test/lapack-test)
==4642==    by 0x42000BE147: ???
==4642==    by 0x42001FFFCF: ???
==4642==    by 0x42001FFFB7: ???
==4642==    by 0x42000BE06F: ???
==4642==    by 0x42001FFFB7: ???

strmm, dtrmm, ztrmm seem not to be affected.

Maybe related to #601?

[martin-frbg]

Could be related indeed, and your backtrace suggests you are using an old version (0.2.18) that still had this bug. Would it be possible for you to try a more recent version ? The fix was committed on the develop branch in october 2017 and the first release to have it would be 0.3.0.

[amigalemming]

On Fri, 21 Sep 2018, Martin Kroeker wrote: Could be related indeed, and your backtrace suggests you are using an old version (0.2.18) that still had this bug. Would it be possible for you to try a more recent version ? The fix was committed on the develop branch in october 2017 and the first release to have it would be 0.3.0.

I am using OpenBLAS from Ubuntu 16.04. Glad to know that there is possibly a fix. Unfortunately I get linker errors when trying OpenBLAS-0.3.3: //usr/lib/libblas.so.3: Nicht definierter Verweis auf `cgemm_thread_ct' //usr/lib/libblas.so.3: Nicht definierter Verweis auf `dgemm_thread_tn' //usr/lib/libblas.so.3: Nicht definierter Verweis auf `csyrk_thread_UT' //usr/lib/libblas.so.3: Nicht definierter Verweis auf `ssymm_thread_LL' //usr/lib/libblas.so.3: Nicht definierter Verweis auf `zgemm3m_thread_rr' ... It seems I have still not convinced the build system to use /opt/openblas instead of the system's default installation of OpenBLAS (/usr/lib/libblas.so.3).

[brada4]

https://github.com/xianyi/OpenBLAS/wiki/faq#debianlts
You can completely remove ubuntu openblas packages.
EDIT:
libblas.so.3 is runtime (ld.so) library. i strongly advise to install blas-dev/lapack-dev packages to have gcc/ld to read reference BLAS (libblas.so) when compiling and dont introduce non-portable dependency on openblas PRIVATE symbols, then later the runtime ld.so will pick the right improved version 3 of BLAS that is replaced with OpenBLAS.

[brada4]

@amigalemming if you use hmatrix you have to disable openblas usage, so that it uses system blas. Probably uninstaling libopenblas0 forces its hand....

[amigalemming]

On Sat, 22 Sep 2018, Andrew wrote: @amigalemming if you use hmatrix you have to disable openblas usage, so that it uses system blas. Probably uninstaling libopenblas0 forces its hand....

I am working on new Haskell bindings for LAPACK that support all matrix types provided by LAPACK. As far as I know, hmatrix would never call ctrmm. If I deinstall openblas would Ubuntu then fall back to unoptimized BLAS routines? I tried to install ATLAS but also got linker errors.

[brada4]

Those are openblas internal symbols that appear missing. They should not be called directly.
two letters in the end are 2 transform parameters that should have been passed through BLAS function.
You can find dispatch functions in interface/* which selects parallel or not, parallel is very bad for small (?but how small) data samples, more accurate calibration is always welcome....

Yes, you will use ld that knows only about functions in (netlib) libblas.so , then at runtime libblas.so.3 will be libopenblas.so
As a result any further consumer will be free to use netlib/atlas/mkl/openblas/cublas/clblas etc

EDIT: those private symbols are not maintained, even less guaranteed, between versions. it could happen (and happens often) that broken parallel function gets disabled for few releases, or broken serial function gets replaced whith parallele version in one thread.
The official API is BLAS, CBLAS, LAPACK, LAPACKE + few utility (not math) functions in openblas cblas.h that deal with detecting build configuration, change maximum threads below number of CPUs, detected CPU type etc.

[amigalemming]

On Sat, 22 Sep 2018, Andrew wrote: Yes, you will use ld that knows only about functions in (netlib) libblas.so , then at runtime libblas.so.3 will be libopenblas.so As a result any further consumer will be free to use netlib/atlas/mkl/openblas/cublas/clblas etc

I have now started a new attempt with openblas-0.3.5 and I managed to integrate the built library into the Debian alternatives system and it seems to work. The linker errors disappeared and the crashes did so as well.