octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59206] crash during matrix multiplication (Wi


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #59206] crash during matrix multiplication (Win only)
Date: Wed, 28 Oct 2020 03:31:28 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36 Edg/86.0.622.51

Follow-up Comment #31, bug #59206 (project octave):

I downloaded the new version and moved it to `mingw64/bin/libblas.dll` inside
Octave 6.0.92's installation folder. In Octave, I ran the following to verify
the correct library is used:

>> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.10 NO_LAPACK NO_LAPACKE DYNAMIC_ARCH
NO_AFFINITY Haswell MAX_THREADS=24)


Fwiw, the output of the same command with the original OpenBLAS library (from
the 6.0.92 installer):

>> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.10 NO_LAPACK NO_LAPACKE DYNAMIC_ARCH
NO_AFFINITY Haswell MAX_THREADS=8)


So, it seems to have correctly picked up the NUM_THREADS setting. The config
string contains "Haswell" (matching my CPU).

Unfortunately, the commands from comment #7 still crash Octave with the new
library.
The gdb backtrace from the crash with the new library:

Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4792.0x240]
0x0000000003a17cee in dgemm_oncopy_HASWELL ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
(gdb) bt
#0  0x0000000003a17cee in dgemm_oncopy_HASWELL ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
#1  0x00000000024c6235 in inner_thread ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
#2  0x000000000261dac4 in blas_thread_server ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
#3  0x00007ff9e35b7034 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#4  0x00007ff9e47dcec1 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)


Maybe there is a reason why Redhat uses "TARGET=CORE2 DYNAMIC_ARCH=1
DYNAMIC_OLDER=1" (see Dmitri's comment #21)...
Should we move in that direction next?
Or should we try if it is fixed with 0.3.12 next?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59206>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]