bugGNU Octave - Bugs: bug #34822, Mingw panics on a simple complex...


bug #34822: Mingw panics on a simple complex product

Submitted by:  Nitzan Arazi <nitnit>
Submitted on:  Mon 14 Nov 2011 07:40:47 PM UTC  
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Nitzan Arazi Open/Closed:  Closed
Release:  3.4.3 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.


( Jump to the original submission)

Fri 06 Apr 2012 04:45:40 PM UTC, comment #26: 

With Nitzan's recent OpenBLAS libblas.dlls this is no more a problem.

The MSVC builds are also stable.

Closing this report.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 06 Apr 2012 03:06:51 PM UTC, comment #25: 

Ping!  Is this still a problem with the latest 3.6.1 builds on MinGW?

Rik <rik5>
Project Administrator
Mon 05 Mar 2012 07:44:36 AM UTC, comment #24: 

Hello Philip,

please recheck your installation because if you have found libblas.dll.altas3.9.19-2 in the 3.6.1 mingw binary - that shouldn't be there !

The only libblas dlls I have bundled are:

  a. libblas.dll.ref - reference blas implementation, very slow but most stable
  b. libblas.dll.libopenblas_dynamicarch-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 2 threads, detects cpu architecture and selects respective lib
  c. libblas.dll.libopenblas_dynamicarch_nt4-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 4 threads, detects cpu architecture and selects respective lib
  d. libblas.dll.libopenblas_nehalemp-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 2 threads, tuned for nehalem cpu architecture
  e. libblas.dll.libopenblas_nehalemp_nt4-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 4 threads, tuned for nehalem cpu architecture
  f. libblas.dll.libopenblas_core2p-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 2 threads, tuned for core2 cpu architecture
  g. libblas.dll.libopenblas_core2p_nt4-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 4 threads, tuned for core2 cpu architecture
  h. libblas.dll.altas-3.8.4_ht-pentium - ATLAS based libblass, tuned for older ht-pentium (compiled by Tatsuro Matsuka)
  i. libblas.dll.altas-3.8.4_corei5 - ATLAS based libblass, tuned for older core i5 cpu (compiled by Tatsuro Matsuka)

Last two are the atlas-3.8.4 you are asking for.


Nitzan Arazi <nitnit>
Sat 03 Mar 2012 09:52:57 PM UTC, comment #23: 

The OpenBLAS dlls contained in the 3.6.1 MinGW binary are still unstable on my PCs.

The only ones that haven't crashed yet are
libblas.dll.refblas (on Pentium M & Core Duo)
libblas.dll.refblas + libblas.dll.libopenblas_dynamicarch-r0.1alpha2.5-0-fda39c6 (on Core Duo)

I used Tatsuro's test, see comment #1:
m = 10000; n = 32; temp = randn (m,n) + i*randn (m,n);
b = temp'* temp;
graphics_toolkit fltk;
demo plotyy   (usually segfaults on the second plot).

Where is atlas-3.8.4 dll? I'd love to try it.
In the 3.6.1 MinGW binary I can only find this one: libblas.dll.altas3.9.19-2

Philip Nienhuis <philipnienhuis>
Project Member
Sat 03 Mar 2012 08:23:18 PM UTC, comment #22: 

I think that with Tatsuro's recent atlas-3.8.4 based dlls and with openblas based dlls which are used in octave-3.6.1 mingw build, this issue is solved.


Nitzan Arazi <nitnit>
Mon 13 Feb 2012 09:57:11 AM UTC, comment #21: 

I have rebuild the OpenBLAS

make CC=i686-pc-mingw32-gcc FC=i686-pc-mingw32-gfortran DYNAMIC_ARCH=1 TARGET=NEHALEM NUM_THREADS=4

The build reports are

 OpenBLAS build complete.

  OS               ... WINNT
  Architecture     ... x86
  BINARY           ... 32bit
  C compiler       ... GCC  (command line : i686-pc-mingw32-gcc)
  Fortran compiler ... GFORTRAN  (command line : i686-pc-mingw32-gfortran)
  Library Name     ... libopenblasp-r0.1alpha2.4.lib (Multi threaded; Max num-threads is 4)

octave:1>  n=2000; A=randn(n); B=randn(n);tic; C=A*B; t=toc, MFLOPS=2*n^3/t*1e-6
t =  0.96606
MFLOPS = 1.6562e+004
t =  1.0561
MFLOPS = 1.5151e+004
t =  0.97106
MFLOPS = 1.6477e+004
t =  1.1741
MFLOPS = 1.3628e+004
t =  0.95905
MFLOPS = 1.6683e+004

The results were the mostly equaled to that were executed previously.

For my case, auto detection seems not to be effective.

Tatsuro MATSUOKA <tmacchant>
Mon 13 Feb 2012 07:27:14 AM UTC, comment #20: 

Hello Tatsuro

As far as I understand, the DYNAMIC_ARCH stores compiled versions for all architecture types in a single dll and upon initialization detects the host cpu architecture and select the proper one. It is possible that it doesn't properly detects your host cpu.

Your cpu (i5-2400) has 4 cores. Have you noticed "Max number of threads" printed by the make process when it finish building ? If it states that the maximal number of threads is 2, try to re-build with NUM_THREADS=4.

Nitzan Arazi <nitnit>
Mon 13 Feb 2012 04:18:50 AM UTC, comment #19: 

I have tried dynamic arch build of OpenBLAS with DYNAMIC_ARCH=1

The performance test results are

octave:1> n=2000; A=randn(n); B=randn(n);tic; C=A*B; t=toc, MFLOPS=2*n^3/t*1e-6

t =  1.0111
MFLOPS = 1.5825e+004
t =  1.0131
MFLOPS = 1.5794e+004
t =  1.0101
MFLOPS = 1.5841e+004
t =  0.99706
MFLOPS = 1.6047e+004
t =  1.0001
MFLOPS = 1.5999e+004

On the other hand, simple build
make CC=i686-pc-mingw32-gcc FC=i686-pc-mingw32-gfortran TARGET=NEHALEM

The performance test results are

n=2000; A=randn(n); B=randn(n);tic; C=A*B; t=toc, MFLOPS=2*n^3/t*1e-6
t =  0.40902
MFLOPS = 3.9118e+004
t =  0.38302
MFLOPS = 4.1773e+004
t =  0.37802
MFLOPS = 4.2326e+004
t =  0.38502
MFLOPS = 4.1556e+004
t =  0.37702
MFLOPS = 4.2438e+004

Simple build has rather higher performance than that of the dynamic architecture build for my case.

(My PC has a Core(TM)i5-2400CPU @3.1GHz, Perhaps Sandy bridge)

I think that the dynamic architecture is a better choice for the stability and convenience from the distribution point of view.  However, the best ability can be available the CPU specific build.

Tatsuro MATSUOKA <tmacchant>
Thu 09 Feb 2012 07:54:37 PM UTC, comment #18: 

Regarding my previous post, the fntests for octave 3.6.0 were in-complete.

I have re-run the full fntests for Octave-mingw-3.4.3 for which I have the full building tree and have tried the OpenBLAS dll.

In relation to the original ATLAS dll (total 5 failures), for the OpenBLAS dll I have got additional 2 failures:

One for svds:

>>>>> processing c:\OctaveB\octave-3.4.3\scripts/sparse\svds.m
  ***** test
s = svds (speye (10));
assert (s, ones (6, 1), 2*eps);
!!!!! test failed
assert (s,ones (6, 1),2 * eps) expected
but got
maximum absolute error 8.88178e-016 exceeds tolerance 4.44089e-016

and one for dec2base

>>>>> processing c:\OctaveB\octave-3.4.3\scripts/strings\dec2base.m
  ***** assert(dec2base(uint64(2)^63-1,16), '7FFFFFFFFFFFFFFF');
!!!!! test failed
assert (dec2base (uint64 (2) ^ 63 - 1, 16),'7FFFFFFFFFFFFFFF') expected
but got

The svds failure may be acceptable but the dec2base failure should be explored.

Nitzan Arazi <nitnit>
Thu 09 Feb 2012 06:33:43 AM UTC, comment #17: 

I didn't run "make check" but instead I have extracted the test sub-directory from


and run fntests. I hope it covers the same testing as "make check".

On my system (core i3) OpenBLAS passes the same tests as with ATLAS - 2 failures on test_system and some skipped tests.


  PASS    827
  FAIL      2

There were 11 skipped tests (see fntests.log for details).
Skipped tests are features that are disabled in this version of Octave
because the needed libraries were not present when Octave was built.

0 (of 30) .m files have no tests.

0 (of 0) .cc files have no tests.

The fntests.log:

>>>>> processing
# >>>>>  new test file
# ?????  no tests in file
# !!!!!  test had an unexpected result
#   *****  code for the test
# Search for the unexpected results in the file
# then page back to find the file name which caused it.
# The result may be an unexpected failure (in which
# case an error will be reported) or an unexpected
# success (in which case no error will be reported).
>>>>> processing test_class_concat
>>>>> processing test_classes
>>>>> processing test_ctor_vs_method
>>>>> processing test_fcn_handle_derived_resolution
>>>>> processing test_args
>>>>> processing test_diag_perm
>>>>> processing test_error
>>>>> processing test_eval-catch
>>>>> processing test_for
>>>>> processing test_func
>>>>> processing test_global
>>>>> processing test_if
>>>>> processing test_index
>>>>> processing test_io
>>>>> processing test_line_continue
>>>>> processing test_logical_index
>>>>> processing test_null_assign
>>>>> processing test_parser
>>>>> processing test_prefer
>>>>> processing test_range
>>>>> processing test_recursion
>>>>> processing test_return
>>>>> processing test_slice
>>>>> processing test_struct
>>>>> processing test_switch
>>>>> processing test_system
  ***** test
orig_umask = umask (0);
nm = tmpnam ();
id = fopen (nm, "wb");
s1 = stat (nm);
fclose (id);
unlink (nm);

umask (777);
nm = tmpnam ();
id = fopen (nm, "wb");
s2 = stat (nm);
fclose (id);
unlink (nm);

assert (deblank (s1.modestr), "-rw-rw-rw-");
assert (deblank (s2.modestr), "----------");
# Restore original umask value
umask (orig_umask);
!!!!! test failed
assert (deblank (s2.modestr),"----------") expected
but got
  ***** testif HAVE_GETPWUID
x = getpwuid (getuid ());
assert ((strcmp (x.dir, tilde_expand ("~"))
&& strcmp (x.dir, tilde_expand (sprintf ("~%s", x.name)))
&& strcmp ("foobar", tilde_expand ("foobar"))));
----- skipped test

  ***** testif HAVE_GETPGRP
assert (getpgrp () > 0);
----- skipped test

  ***** testif HAVE_GETPPID
assert (getppid () > 0);
----- skipped test

  ***** assert (getenv ("HOME"), tilde_expand ("~"))
!!!!! test failed
assert (getenv ("HOME"),tilde_expand ("~")) expected
but got

  ***** testif HAVE_GETPWENT
s = getpwent ();
endpwent ();
assert ((isstruct (s)
&& isfield (s, "name")
&& isfield (s, "passwd")
&& isfield (s, "uid")
&& isfield (s, "gid")
&& isfield (s, "gecos")
&& isfield (s, "dir")
&& isfield (s, "shell")));
----- skipped test

  ***** testif HAVE_GETPWUID
x = getpwent ();
y = getpwuid (x.uid);
endpwent ();
assert (strcmp (x.name, y.name) && x.uid == y.uid && x.gid == y.gid);
----- skipped test

  ***** testif HAVE_GETPWNAM
x = getpwent ();
y = getpwnam (x.name);
endpwent ();
assert (strcmp (x.name, y.name) && x.uid == y.uid && x.gid == y.gid);
----- skipped test

  ***** testif HAVE_SETPWENT
x = getpwent ();
setpwent ();
y = getpwent ();
endpwent ();
assert (strcmp (x.name, y.name) && x.uid == y.uid && x.gid == y.gid);
----- skipped test

  ***** testif HAVE_GETGRENT
x = getgrent ();
endgrent ();
assert ((isstruct (x)
&& isfield (x, "name")
&& isfield (x, "passwd")
&& isfield (x, "gid")
&& isfield (x, "mem")));
----- skipped test

  ***** testif HAVE_GETGRGID
x = getgrent ();
y = getgrgid (x.gid);
endgrent ();
assert (strcmp (x.name, y.name) && x.gid == y.gid);
----- skipped test

  ***** testif HAVE_GETGRNAM
x = getgrent ();
y = getgrnam (x.name);
endgrent ();
assert (strcmp (x.name, y.name) && x.gid == y.gid);
----- skipped test

  ***** testif HAVE_SETGRENT
x = getgrent ();
setgrent ();
y = getgrent ();
endgrent ();
assert (strcmp (x.name, y.name) && x.gid == y.gid);
----- skipped test

>>>>> processing test_transpose
>>>>> processing test_try
>>>>> processing test_unwind
>>>>> processing test_while

Files with no tests:

Nitzan Arazi <nitnit>
Wed 08 Feb 2012 11:02:31 PM UTC, comment #16: 

Because of unknown reason, using OpenBLAS at build stage give make check failures (octave crash!). Therefore I will continue to use the ATLAS for building octave.  However, replacing libblas.dll by OpenBLAS gives only one more "make check" FAIL (test svds.m).  However, the svds.m test FAIL is very delicate. It strongly dependent on the environments: https://savannah.gnu.org/bugs/?func=detailitem&item_id=29721

BTW, how about OpenBLAS old computer that uses Pentium-4.  I have never tested.

Anyway libblas.dll can be replaceable so that we can prepare and provide libblas.dll even for the old CPU.

Tatsuro MATSUOKA <tmacchant>
Wed 08 Feb 2012 08:29:38 PM UTC, comment #15: 

Yes, the OpenBLAS license is completely acceptable for Octave, and I'm glad to see it being put to good use.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 08 Feb 2012 08:03:24 PM UTC, comment #14: 

I have successfully cross-compiled (cygwin to mingw) OpenBLAS for dynamic architecture. The created dll can be used on various platforms and suppose to automatically select the respective optimized code.

I have tried it on different machines (core, nehalem) with 2 and 4 cores and it give much better performance than the ATLAS3.9.19 dll (tuned by Tatsuro for core i5). I couldn't repoduce  encounter the #34822 bug, at least with the reported test cases.

I think that this (OpenBLAS dynamic-architecture) dll may be suitable for the mingw binary distribution (at least as an alternative to Tatsuros re-compiled ATLAS 3.8).

I just wonder whether its licesnse (BSD ?) is compatible with octave license.

Nitzan Arazi <nitnit>
Sat 04 Feb 2012 12:35:53 AM UTC, comment #13: 

I have recently successfully built ATLAS 3.8.4.  This ATLAS seem to fix the issue. I will provide this binary for the Octave-3.6.1.

Tatsuro MATSUOKA <tmacchant>
Fri 03 Feb 2012 03:48:05 PM UTC, comment #12: 

Trying Nitzan's code from comment #1 makes my Octave-3.6.0 MinGW window disappear -> i.e., a hard crash.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 28 Jan 2012 08:02:58 PM UTC, comment #11: 

The question is different to answer. For Atals-3.9.19 for Cerelon-M and Ht-pentium I worked long ago.  However, ATLAS-3.9.19 is rather old(Decemner 2009). So I tried ATLAS-3.8.4 (May 2011), which is rather new. And ATLAS 3.8.4 is stable release on a lot of ATLAS releases.

Build for 3.8.4 for corei5 seems to be good. And I also tried changing compiler to gcc-4.5.3 and 4.6.2. Combination gcc-4.5.3 and ATLAS 4.8.4 seems to be fine. I have to try the combination to older CPUs. However they are time consuming events so that I have not completed yet.

This is my guess at the moment.  We cannot prepare one blas that works fine on all CPUs. We have to compromise on this point. Otherwise it is better prepare to some kinds of blas (ALTAS and openBLAS).  It is also important the way the generating optimized blas for the users' CPU on the wiki.

Tatsuro MATSUOKA <tmacchant>
Fri 27 Jan 2012 07:36:16 AM UTC, comment #10: 

Hello Tatsuro,

Regarding the compilation of ALTALS-3.9.19 with gcc+gfortran-4.3.4, can you elaborate how the optimization can be controlled for different target cpus ?

Nitzan Arazi <nitnit>
Fri 27 Jan 2012 01:26:54 AM UTC, comment #9: 

I have succeed to buils ATLAS 3.8.4. That is newer than ATLAS 3.9.19.

However, simple replacement of libblas.dll could not be made due to the DLL entry point error. One has to build octave with the ALTAS 3.8.4.

Now I have complied gcc-4.6.2 on the cygwin and could build this new altas.

However, with this new atlas, the number of make check error increased. The reason is not understandable.

I will look into further.

Tatsuro MATSUOKA <tmacchant>
Mon 23 Jan 2012 07:18:36 AM UTC, comment #8: 

I have upload a new BLAS (ATLAS 3.9.19 optimized for Core i5).

libblas.Atlas3.9.19.Corei5.7z, 473,695 bytes, 2012-01-23, md5 7a56f84fcee7c0ace0ec0dd12d2c768c, libblas.dll using ATLAS-3.9.19m opimized for Core i5

Tatsuro MATSUOKA <tmacchant>
Mon 23 Jan 2012 07:06:33 AM UTC, comment #7: 

For the ATLAS, I have not gotten successful result for the cross compiling.  I have been used a tricky technique to build the ATLAS.

First I have built gcc + gfortran (4.3.4) on the cygwin without any cygwin specific patches.

cd build

../gcc-4.3.4/configure  --disable-bootstrap --enable-static --enable-shared --enable-shared-libgcc --enable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++,fortran --disable-symvers --enable-libgomp --enable-libssp --enable-threads=posix --with-arch=i686 --with-tune=generic --with-gmp --with-mpfr --prefix=/usr/local/gcc-4.3.4np

make install

With this gcc, I can build the ATLAS libraries which can be linked the MinGW gcc.

export PATH=/usr/local/gcc-4.3.4np/bin:$PATH
gcc -v ; gfortran -v
cd "E:\usr\Tatsu\cyghome-1.7\atlas\atlas-3.9.19build4"

../ATLAS-3.9.19/configure -t 1

make install

copy lib*.a /usr/local/atlas/lib to the appropriate directory.


gfortran -shared-libgcc -shared \
-Wl,--enable-auto-import \
-Wl,--enable-runtime-pseudo-reloc-v2 \
-Wl,--allow-multiple-definition \
-Wl,--out-implib=libblas.dll.a -o libblas.dll \
-Wl,--output-def=libblas.exp \
-Wl,--whole-archive libf77blas.a \
-Wl,--no-whole-archive libatlas.a

You can get libblas.dll and libblas.dll.a

The reason why I use the ATLAS 3.9.19 is a mere incident.

I have tried the recent version of the ATLAS but the builds have been in failure.

I will upload the libblas optimized for Core i5-2400 CPU @ 3.10 GHz on my web site.

I will continue to struggle with the ATLAS and the OpenBLAS.

The Matrix calculation seem to depend on the combination the BLAS and the CPU on the PC.
We may have to prepare sevral kind of BLAS packages for the END user.

Tatsuro MATSUOKA <tmacchant>
Sun 22 Jan 2012 07:56:35 AM UTC, comment #6: 

I have tested Tatsuro's compilation of 3.6.0/OctaveLibs/gplibs (gcc 462)

I am getting this crash with
a. Tatsuro's libblas.dll (from OctaveLibs.7z bin)
b. Tatsuro's libblas.dll.altas3.9.19-2 (from OctaveLibs.7z bin, renamed to libblas.dll) - this binary is almost identical to the original libblas.dll in OctaveLibs.7z bin !

I am not getting this crash with
c. libblas.dll.openblas_a546694 (from OctaveLibs.7z bin, renamed to libblas.dll)
d. libblas.dll cross compiled (by myself using cygwin) from openblas source

Tatsuro, can you give more details and references to the ATLAS-3.9.19 based libblas you have cross compiled which has passed this test ?

Nitzan Arazi <nitnit>
Sat 24 Dec 2011 10:59:00 PM UTC, comment #5: 

I have tested on my PC at home using libblas from ATLAS-3.9.19.
This ATLAS blas was made by the used PC itself.

The test


did not cause error.

I think that the phenomena come from the combination of the blas and the CPU used.

Tatsuro MATSUOKA <tmacchant>
Wed 16 Nov 2011 11:24:01 PM UTC, comment #4: 

Sorry for not giving enough information.

I have uplaod libblas.dll in zip form:

I have forgotten to write important point
in section 3 of


To make libblas.dll which is replaceable with libblas.dll in current octave 3.4 distribution, the following for example is required. 

i686-pc-mingw32-gcc -shared-libgcc -shared \
-Wl,--enable-auto-import \
-Wl,--enable-runtime-pseudo-reloc-v2 \
-Wl,--allow-multiple-definition \
-Wl,--out-implib=libblas.dll.a -o libblas.dll \
-Wl,--output-def=libblas.exp \
-Wl,--whole-archive libopenblas_core2p-r0.1alpha2.2.lib \
-Wl,--no-whole-archive  -lgfortran

Hope this helps

Tatsuro MATSUOKA <tmacchant>
Wed 16 Nov 2011 06:06:53 PM UTC, comment #3: 


It seems that some details are missing from the end of your post.

Can you please provide more information regarding how you have cross compiled libblas.dll from openblas ?

I have tried to follow the procedure from section 3 of


and for some reason I am getting 'The procedure entry point ilaenv_ could not be located in the dynamic link library libblas.dll' error when starting octave, I assume that there is a problem with dll I have built.

Is it possible that you will upload the dll that you have built to your site ?


Nitzan Arazi <nitnit>
Wed 16 Nov 2011 03:20:52 AM UTC, comment #2: 

I have confirmed that


caused segfault.

However, I have replaced libblas.dll by produced by Openblas on my computer (core-i5, win 7 64bit).

octave:1> m=10000;
octave:2> n=32;
octave:3> temp=randn(m,n)+i*randn(m,n);
octave:4> b=temp'*temp;

Segfault did not occur.
I have not been successful result building the ATLAS on my computer.

I did

Tatsuro MATSUOKA <tmacchant>
Mon 14 Nov 2011 07:44:42 PM UTC, comment #1: 

On mingw 3.4.3 and 3.4.2, win7-x64, no packages loaded,
running the following code cause a segmentation violation:


The crash may happen also when running several time with smaller m:

for ii=1:1000
for ii=1:1000

On my system, the crash occurs on the second loop when ii=11.

Nitzan Arazi <nitnit>
Mon 14 Nov 2011 07:40:47 PM UTC, original submission:  

On mingw 3.4.3 and 3.4.2, win7-x64, no packages loaded,
running the following code cause a segmentation violation:

Nitzan Arazi <nitnit>


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

Attach Files:

No files currently attached


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Posted a comment)
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by nitnit (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.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-11-30 jordigh Dependencies- => Depends on bugs #35769
    2012-04-06 philipnienhuis StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
    2012-04-06 rik5 StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5