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

 
 

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

Submitted by:  Hartmut <hardy>
Submitted on:  Wed 30 Sep 2020 12:34:21 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  6.0.90 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project Member
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>
Project 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>
Project 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>
Project Member
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:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-30 mmuetzel StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5