bugGNU Octave - Bugs: bug #59206, crash during matrix multiplication...

 
 

bug #59206: crash during matrix multiplication (Win only)

Submitter:  Hartmut <hardy>
Submitted:  Wed 30 Sep 2020 12:34:21 PM UTC
   
 
Category:  Octave Function Severity:  4 - Important
Priority:  7 - High Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.0.92 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 28 Oct 2020 01:52:53 PM UTC, comment #37: 

Thanks for supplying the test libraries and pushing the patch.

Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Oct 2020 01:41:08 PM UTC, comment #36: 

I pushed the change for mxe-octave:

https://hg.octave.org/mxe-octave/rev/c93838f0bcf2

OK to close this report as fixed then?

John W. Eaton <jwe>
Group administrator
Wed 28 Oct 2020 01:27:24 PM UTC, comment #35: 

With the new dll:

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


Octave no longer crashes with the commands from comment #7.
So it very much looks like a bug in OpenBLAS 0.3.10 that has since been fixed.

I'll push the patch updating to the new version probably some time later today if no one else beats me to it.

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Oct 2020 01:08:54 PM UTC, comment #34: 

Yes, I'm using a fresh mxe-octave build that has GCC 9.3.0.

Markus:  Try this version:

https://jweaton.org/libopenblas.dll-0.3.12.gz

If that works, then I'll conclude that we are hitting some problem with OpenBLAS 0.3.10 that is fixed in 0.3.12 and that we should just update to 0.3.12 with your patch for the OpenBLAS build rules in mxe-octave.  If it still doesn't work for you, then I'll have to try to find out what it is about my build system that is causing the trouble.

John W. Eaton <jwe>
Group administrator
Wed 28 Oct 2020 12:05:37 PM UTC, comment #33: 

I suppose jwe was using MXE Octave to build the library.
The (cross-)compiler we currently build in MXE Octave is gcc version 9.3.0.

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Oct 2020 11:14:35 AM UTC, comment #32: 

I am pretty sure Haswell is a superset of Core2Duo (that I have), so I strongly suspect it is a bug in 0.3.10 that causing that issue.

John, what is your gcc compiler version? There were few compiler bugs in the past when it would issue instructions set present in the host even when asked not too. But then it is hard to understand why would it crash Haswell, but not Core2Duo.

As far as I know Piledriver CPU has   TBM (Trailing Bit Manipulation) instruction set that no-one else has.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Oct 2020 07:31:27 AM UTC, comment #31: 

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?

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Oct 2020 04:53:35 AM UTC, comment #30: 

Markus: I used your patch but omitted the updates for the 0.3.10 -> 0.3.12 update.  With my build, the log file showed:


 OpenBLAS build complete. (BLAS)

  OS               ... WINNT
  Architecture     ... x86_64
  BINARY           ... 64bit
  C compiler       ... GCC  (cmd & version : x86_64-w64-mingw32-gcc (GCC) 9.3.0)
  Fortran compiler ... GFORTRAN  (cmd & version : GNU Fortran (GCC) 9.3.0)
  Library Name     ... libopenblasp-r0.3.10.a (Multi-threading; Max num-threads is 24)
  Supporting multiple x86_64 cpu models with minimum requirement for the common code being PRESCOTT


You can find the resulting DLL file here:

https://jweaton.org/libopenblas.dll.gz

Could you try using this version and see whether you still see the crash?

John W. Eaton <jwe>
Group administrator
Tue 27 Oct 2020 08:47:47 PM UTC, comment #29: 

@Kai, comment #18:
Yes, the w64 installer 2020-10-26-02-31 crashes here with that code in comment #7.

Looks like my WAG in comment #16 wasn't so bad.

[Slightly OT]
Maybe this also explains crashes I've been seeing for years at work, where for groundwater model input a large sparse matrix is multiplied with an equally large diagonal one; same behavior. The invocation itself is correct and has been working with Matlab for over a decade.
That crash is one of the main showstoppers when I tried to persuade my colleagues try Octave instead of Matlab. So, perhaps my Core i5 at home doesn't match the (older) dual Xeons at work.
I should have tried with ref BLAS ... (will do)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 27 Oct 2020 07:14:54 PM UTC, comment #28: 

Without the patch, logs/openblas showed:

 OpenBLAS build complete. (BLAS)

  OS               ... WINNT
  Architecture     ... x86_64
  BINARY           ... 64bit
  C compiler       ... GCC  (cmd & version : x86_64-w64-mingw32-gcc (GCC) 9.3.0)
  Fortran compiler ... GFORTRAN  (cmd & version : GNU Fortran (GCC) 9.3.0)
  Library Name     ... libopenblasp-r0.3.10.a (Multi-threading; Max num-threads is 4)
  Supporting multiple x86_64 cpu models with minimum requirement for the common code being HASWELL


Maybe an Intel vs. AMD compatibility issue?

Markus Mützel <mmuetzel>
Group administrator
Tue 27 Oct 2020 04:57:39 PM UTC, comment #27: 

I used the attached patch to cross-compile version 0.3.12 of OpenBLAS with the additional settings for TARGET and NUM_THREADS.
With that patch, TARGET will be set to "KATMAI" when we are building for Windows 32bit. Otherwise, it will be set to "PRESCOTT". This assumes that all other targets (incl. native Linux) are 64bit. I don't know if this assumption is save enough.
It will set NUM_THREADS to 24 (which I thought was reasonably high).

One hunk from a patch we have in MXE Octave (referring to xerbla) no longer applies. I just removed that hunk and compilation went smoothly. I'm not sure if this is ok or if we need an alternative change.

Anyway, on Windows, I used the "BLAS Switcher" to select OpenBLAS. Running `version -blas` confirmed that OpenBLAS was used.
With that, I ran the test suite.
I had some local changes in Octave. Because of those, some tests failed. But these test failures seem unrelated.
Also the code from comment #7 didn't crash Octave. (But it never did when MXE Octave was compiled on the same machine.)
So, I guess OpenBLAS works correctly for me with this change.

(file #50139)

Markus Mützel <mmuetzel>
Group administrator
Tue 27 Oct 2020 02:53:57 PM UTC, comment #26: 

Markus: By default, NUM_THREADS appears to be set to the number of cores on the build system, even when cross compiling.

John W. Eaton <jwe>
Group administrator
Tue 27 Oct 2020 02:50:29 PM UTC, comment #25: 

For x86 it is got to be katmai...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 27 Oct 2020 02:43:59 PM UTC, comment #24: 

With respect to the TARGET value:

> For x86_64, the list of targets this activates contains Prescott, Core2, Nehalem, Barcelona, Sandybridge, Bulldozer, Piledriver, Steamroller, Excavator, Haswell, Zen, SkylakeX.

And:

> DYNAMIC_ARCH is also supported on x86, where it translates to Katmai, Coppermine, Northwood, Prescott, Banias, Core2, Penryn, Dunnington, Nehalem, Athlon, Opteron, Opteron_SSE3, Barcelona, Bobcat, Atom and Nano.


We should probably select one from those lists depending on whether we are building x86_64 or x86 executables.

Markus Mützel <mmuetzel>
Group administrator
Tue 27 Oct 2020 02:39:59 PM UTC, comment #23: 

Is "Max num-threads" dependent on the target? Or should we set that explicitly as well?

The makefile of OpenBLAS contains the following:

# Note for package maintainers: you can build OpenBLAS with a large NUM_THREADS
# value (eg. 32-256) if you expect your users to use that many threads. Due to the way
# some internal structures are allocated, using a large NUM_THREADS value has a RAM
# footprint penalty, even if users reduce the actual number of threads at runtime.
# NUM_THREADS = 24


Markus Mützel <mmuetzel>
Group administrator
Tue 27 Oct 2020 02:14:17 PM UTC, comment #22: 

The log/openblas file in my mxe-octave for the w64 build with the default 32-bit integers for indexing shows


 OpenBLAS build complete. (BLAS)

  OS               ... WINNT
  Architecture     ... x86_64
  BINARY           ... 64bit
  C compiler       ... GCC  (cmd & version : x86_64-w64-mingw32-gcc (GCC) 9.3.0)
  Fortran compiler ... GFORTRAN  (cmd & version : GNU Fortran (GCC) 9.3.0)
  Library Name     ... libopenblasp-r0.3.10.a (Multi-threading; Max num-threads is 8)
  Supporting multiple x86_64 cpu models with minimum requirement for the common code being PILEDRIVER


On the older system where I built a w32 binary, the common code arch is BARCELONA and Max num-threads is 6.  So those values to appear to be selected based on the build system.

John W. Eaton <jwe>
Group administrator
Tue 27 Oct 2020 01:49:13 PM UTC, comment #21: 

I would think "OPTERON" is the oldest,
RedHat uses "TARGET=CORE2 DYNAMIC_ARCH=1 DYNAMIC_OLDER=1"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 27 Oct 2020 01:18:18 PM UTC, comment #20: 

The readme of OpneBLAS contains:

> The TARGET option can be used in conjunction with DYNAMIC_ARCH=1 to specify which cpu model should be assumed for all the common code in the library, usually you will want to set this to the oldest model you expect to encounter.


Currently, we don't set TARGET. That might mean the "common code" is built for the CPU on the build system. Maybe, we should set target to something (not sure to what).

I'm currently trying to build OpenBLAS 0.3.12 in MXE Octave. I'll upload a patch if this should succeed.

Markus Mützel <mmuetzel>
Group administrator
Tue 27 Oct 2020 10:33:46 AM UTC, comment #19: 

There is an "official" win library

https://github.com/xianyi/OpenBLAS/releases/download/v0.3.12/OpenBLAS-0.3.12-x64.zip

Can anyone who has a problem replace liopenblas.dll.a and see if that helps?
It works for me but I did not see the problem with the original.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 27 Oct 2020 09:49:54 AM UTC, comment #18: 

comment #16:

> I read somewhere that OpenBLAS is optimized for the box it is built on; maybe that explains why my own crossbuilds runs fine here but the OpenBLAS built on JWE's PC and shipped with 6.0.92 is unstable on my box? (just a WAG)


Does it crash in this case, if you take one of my builds?  https://octave.space

In general, mxe is build with "support [of] multiple architecture[s] in one binary" with `DYNAMIC_ARCH = 1`, see

https://hg.octave.org/mxe-octave/file/ee3807ebbd74/src/openblas.mk#l13

https://github.com/xianyi/OpenBLAS/blob/e2f9005db8cfd0be406a1ba726194d577e3a5ec7/Makefile.rule#L17-L18

Kai Torben Ohlhus <siko1056>
Group Member
Tue 27 Oct 2020 07:45:17 AM UTC, comment #17: 

Still no crash for Octave 6.0.90 or 6.0.92 with OpenBLAS on MS Windows 10 Home (v2004) for the code of comment #7.

Dell laptop with Intel(R) Core(TM) i7-10710U.

Kai Torben Ohlhus <siko1056>
Group Member
Mon 26 Oct 2020 10:30:04 PM UTC, comment #16: 

Hmm, I can reproduce the crash as well with 6.0.92, using the code from comment #7. Immediately after entering the last command ('PD = inv (P) * D;') Octave seems to be busy for a a few seconds (cursor changing shape) and then it is gone w/o a trace.

However, in a 7.0.0 crossbuild from Oct, 23 I see no crash. After the last command Octave does not need much time, it returns almost immediately to the prompt.

All on Windows 10 Professional 64b on an older Core i5-4570.

I read somewhere that OpenBLAS is optimized for the box it is built on; maybe that explains why my own crossbuilds runs fine here but the OpenBLAS built on JWE's PC and shipped with 6.0.92 is unstable on my box? (just a WAG)

Philip Nienhuis <philipnienhuis>
Group Member
Mon 26 Oct 2020 08:45:09 PM UTC, comment #15: 

I don't mind making another test release if it is needed.  But before doing that, could someone who is having this problem attempt a build with the update OpenBLAS library and see whether it fixes the issue?

Or, I could build an updated OpenBLAS DLL using version 3.12 and provide it to someone who is having the issue.

John W. Eaton <jwe>
Group administrator
Mon 26 Oct 2020 06:48:44 PM UTC, comment #14: 

We are currently building OpenBLAS 0.3.10 in MXE Octave. There seems to be a new upstream release (0.3.12):
https://github.com/xianyi/OpenBLAS/releases

Some changes in 0.3.11 and 0.3.12 sound like they could be related.

Maybe, we should just update and look if that fixes the issue.

@jwe: Do you plan to make another release candidate before the final release?

Markus Mützel <mmuetzel>
Group administrator
Mon 26 Oct 2020 05:04:04 PM UTC, comment #13: 

I'm also not running in a VM.  I have a laptop with a Core i5-7300U CPU and Windows 10 Enterprise 1709.

John W. Eaton <jwe>
Group administrator
Mon 26 Oct 2020 04:16:57 PM UTC, comment #12: 

I have also retested this. And I still get a crash on both Win10 PCs with the current Octave 6.0.92 win installer (also using Markus' easier code from comment #7).

Here are the processor and OS details on my two PCs with a native Win 10 installation (no VM):

  • processor: Intel Core i7-8650U CPU @ 1.9 GHz - 2.11 GHz, Windows 10 Enterprise LTSC (Version: 1809)
  • processor: Intel Core i3-8100T CPU @ 3.1 GHz - 3.1 GHz, Windows 10 Pro (Version: 2004)
Hartmut <hardy>
Mon 26 Oct 2020 03:05:03 PM UTC, comment #11: 

I have an Intel Core i5-4690 CPU and tested with Windows 10 Pro (2004).

Markus Mützel <mmuetzel>
Group administrator
Mon 26 Oct 2020 02:31:32 PM UTC, comment #10: 

Works for me (no crash) with the installer on Core2Duo Win 7 Home
(see attached).

Dmitri.
--



Dmitri A. Sergatskov <dasergatskov>
Mon 26 Oct 2020 01:47:05 PM UTC, comment #9: 

I'm unable to reproduce using the 6.0.92 binary from the installer that I uploaded to alpha.gnu.org.  I'm executing it on a Windows 10 system.

John W. Eaton <jwe>
Group administrator
Mon 26 Oct 2020 01:22:22 PM UTC, comment #8: 

Markus,

What is the CPU on your computer?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 26 Oct 2020 12:14:50 PM UTC, comment #7: 

Easier steps to reproduce:

P = rand (3);
D = rand (3, 772902);
PD = inv (P) * D;


Markus Mützel <mmuetzel>
Group administrator
Mon 26 Oct 2020 12:11:48 PM UTC, comment #6: 

The crash is still happening for me with 6.0.92.
Same backtrace:

Thread 3 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 18420.0x2a14]
0x00000000029800ee in libopenblas!dcabs1_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
(gdb) bt
#0  0x00000000029800ee in libopenblas!dcabs1_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
#1  0x0000000001c961d5 in zgemm3m_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
#2  0x0000000001dec534 in openblas_get_parallel_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.92\mingw64\bin\libblas.dll
#3  0x00007ffae8747034 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#4  0x00007ffaea29cec1 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)


Since this wasn't mentioned before. The crash happens at this line:

PD = inv(P)*D;


`P` is a 3x3 full double matrix, `D` is a 3x772902 full double matrix.

Raising priority since this hints on something being wrong with the LAPACK functions in the OpenBLAS library we package for Windows.
Since this doesn't happen when I build for Windows on my machine, I guess the issue is from differences on the build system (or maybe differences between the build and host systems?).
IIUC, the intention of MXE Octave is to build executables that don't depend on the build system. (Not sure if this is strictly true.)
This might hint at a problem in MXE Octave.

CC'ing jwe because the release candidates were built on his machine.

Markus Mützel <mmuetzel>
Group administrator
Mon 26 Oct 2020 09:35:18 AM UTC, comment #5: 

I cannot confirm this crash neither with Octave 6.0.90 nor 6.0.92 with OpenBLAS on MS Windows 10 Home (v2004) 🤔

Can you check if this is still an issue with Octave 6.0.92 for you?

Kai Torben Ohlhus <siko1056>
Group Member
Thu 01 Oct 2020 11:52:31 AM UTC, comment #4: 

It doesn't crash for me if I build from the stable branch (Octave 6.0.91). I can't find the hg id of my build in the repo (I must have had some local changes applied that I since have stripped). But I made the build shortly after hg id 7e0712b3388f to confirm that that change fixed a crash on startup.

It looks like only the release candidate is affected.
Maybe something at that particular revision? Or a difference in the build systems?

Markus Mützel <mmuetzel>
Group administrator
Thu 01 Oct 2020 11:35:07 AM UTC, comment #3: 

In a 7.0.0 build from Aug. 23 it works fine too (as expected), so this is definitely an issue with the stable release.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 30 Sep 2020 05:41:07 PM UTC, comment #2: 

FTR, works fine (no crash) in Octave-7.0.0 crossbuilt Sept. 25.

My mxe-octave build tree doesn't have that binutils cset (yet), it's currently at https://hg.octave.org/mxe-octave/rev/d862fd40cc42 "Use ccache for packages built with cmake".

Philip Nienhuis <philipnienhuis>
Group Member
Wed 30 Sep 2020 02:02:25 PM UTC, comment #1: 

I can reproduce the crash with 6.0.90 using OpenBLAS.
gdb backtrace from the crash:

Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 19580.0x4474]
0x0000000001de00ee in libopenblas!dcabs1_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\bin\libblas.dll
(gdb) bt
#0  0x0000000001de00ee in libopenblas!dcabs1_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\bin\libblas.dll
#1  0x00000000010f61d5 in zgemm3m_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\bin\libblas.dll
#2  0x000000000124c534 in openblas_get_parallel_ ()
   from C:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\bin\libblas.dll
#3  0x00007ff8baeb6fd4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#4  0x00007ff8bcd5cec1 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)


The crash doesn't happen with reference BLAS.

I cannot reproduce with a build from stable hg id 7778bc023114 with MXE Octave hg id e2582a427c2a. The same for reference BLAS and OpenBLAS.

The only change to the OpenBLAS build rule in MXE Octave after the release candidate was this one:
https://hg.octave.org/mxe-octave/rev/c475092f8142
openblas: Support using ccache.

But I don't see how that could have any influence.

Could the updated binutils have fixed this?
https://hg.octave.org/mxe-octave/rev/bc8ef5fda77b
src/build-binutils.mk, src/native-binutils.mk: update to v2.35.1

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 12:34:21 PM UTC, original submission:  

I have observed a reproducibly crash of Octave 6.0.90 GUI. It only happens under Windows 10, not under Linux OS. I have not observed this crash with Octave 5.2.0 under Windows. (I can also NOT generate this crash with Octave 6.0.90 CLI, but with the CLI version I seem to get a wrong result.)

Here is how to reproduce the crash. The following example code uses functions (only m-code) from the image package (the current version that is included within the 6.0.90 Win installer), but I fear that this behavior is not only due to the image package, but due to core Octave.

1. start the Octave 6.0.90 GUI under Win 10
2. pkg load image, edit imperspectivewarp
   set a breakpoint on line 111 (D = [X(:).......)
3. execute the following simple m-code:


pkg load image
clear
I = ones(649, 1000); % different sizes -> no crash
J = imrotate(I, 5);


4. The code execution will stop at the set breakpoint.
   Make it execute the next line (line 112)
   -> CRASH

The critical code line ( PD = inv(P)*D; ) contains an matrix inverse calculation and a matrix multiplication. I have seperated this into two different code lines. The inverse computation works fine then. The crash happens afterwards during the matrix multiplication. The critical multiplication has two double type matrices as input, a 3-by-3 and a 3-by-772902 matrix.

When using Octave 6.0.90 CLI version (instead of the GUI version above) I do not observe a crash. But in this case I seem to get a wrong calculation result. This can be seen when executing "imshow(J)" after the above m-script. It should show a white rectangle turned by 5 degrees, buit is has a "noisy stripe" running through the result image J.

I have no idea what goes wrong here. But it doesn't look good to me, that Octave crashes reproducibly during a multiplication of two reasonably sized double matrices (nor that this gives a presumably wrong result).

Can anyone else reproduce this? Any ideas what goes wrong here?

Hartmut <hardy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #50139:  bug59206_openblas_0.3.12.patch added by mmuetzel (4KiB - application/octet-stream)
file #50108:  win_octave2.png added by dasergatskov (167KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-28 mmuetzel StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2020-10-27 mmuetzel Attached File- Added bug59206_openblas_0.3.12.patch, #50139
        StatusConfirmed Patch Submitted
    2020-10-26 dasergatskov Attached File- Added win_octave2.png, #50108
    2020-10-26 mmuetzel Severity3 - Normal 4 - Important
        Priority5 - Normal 7 - High
        StatusNeed Info Confirmed
        Carbon-Copy- Added jwe
    2020-10-26 siko1056 StatusConfirmed Need Info
        Release6.0.90 6.0.92
    2020-09-30 mmuetzel StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code