openblas segfault?

[Jonathan Bober]

I'm getting a segfault on the current development branch of sage (see below). Is this a known issue and/or effecting anyone else?

This does not happen for me in Sage 7.3, although it does happen if I try to go "back in time" with a 'git checkout 7.3' and then rebuild. So just to be certain I built a few copies from scratch.

This is from a doctest in src/doc/*/a_tour_of_sage/index.rst, easily reproducible. (Notice the * there. I guess Sage separately tests the documentation in each language...)

sage: m = random_matrix(RDF,500)

sage: m.eigenvalues()

------------------------------------------------------------------------

/data/home/jb12407/sources/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x4635)[0x7f6d34da4635]

/data/home/jb12407/sources/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x4685)[0x7f6d34da4685]

/data/home/jb12407/sources/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x7107)[0x7f6d34da7107]

/lib64/libpthread.so.0[0x30f700f7e0]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(daxpy_k+0x48)[0x7f6d29e9eab8]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(+0xc9c3e)[0x7f6d29ca9c3e]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(exec_blas+0xd9)[0x7f6d29e590f9]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(dtrmv_thread_NLU+0x204)[0x7f6d29ca9f34]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(dtrmv_+0x155)[0x7f6d29c67b75]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(dlahr2_+0x451)[0x7f6d2a0eecb1]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(dgehrd_+0x47d)[0x7f6d2a0b6c8d]

/data/home/jb12407/sources/sage/local/lib/libopenblas.so.0(dgeev_+0x430)[0x7f6d2a0b1470]

/data/home/jb12407/sources/sage/local/lib/python2.7/site-packages/scipy/linalg/_flapack.so(+0x2cde7)[0x7f66808b4de7]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f6d4244aed3]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x388a)[0x7f6d424fd5ba]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(+0x839fc)[0x7f6d4247b9fc]

/data/home/jb12407/sources/sage/local/lib/python2.7/site-packages/sage/matrix/matrix_double_dense.so(+0x9949)[0x7f6682759949]

/data/home/jb12407/sources/sage/local/lib/python2.7/site-packages/sage/matrix/matrix_double_dense.so(+0x5161b)[0x7f66827a161b]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5331)[0x7f6d424ff061]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f6d42500789]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x509e)[0x7f6d424fedce]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5654)[0x7f6d424ff384]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f6d4250066c]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f6d42500789]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyRun_FileExFlags+0x8a)[0x7f6d42523e5a]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0xd7)[0x7f6d42525207]

/data/home/jb12407/sources/sage/local/lib/libpython2.7.so.1.0(Py_Main+0xc3e)[0x7f6d4253b70e]

/lib64/libc.so.6(__libc_start_main+0xfd)[0x30f6c1ed1d]

python[0x4006f1]

------------------------------------------------------------------------

Attaching gdb to process id 56935.

GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)

Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

(gdb) Hangup detected on fd 0

error detected on stdin

Your system GDB is an old version that does not work with pipes

Install gdb for enhanced tracebacks.

------------------------------------------------------------------------

Unhandled SIGSEGV: A segmentation fault occurred.

This probably occurred because a *compiled* module has a bug

in it and is not properly wrapped with sig_on(), sig_off().

Python will now terminate.

------------------------------------------------------------------------

[Dima Pasechnik]

I guess more details are needed, like CPU type (what does lscpu tell?)

For me, on  i7-6600U CPU @ 2.60GHz, it  works:

sage: m = random_matrix(RDF,500)

sage: e=m.eigenvalues()

sage: len(e)

500

[Jonathan Bober]

jb12407@lmfdb5:~$ lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                64

On-line CPU(s) list:   0-63

Thread(s) per core:    2

Core(s) per socket:    8

Socket(s):             4

NUMA node(s):          8

Vendor ID:             AuthenticAMD

CPU family:            21

Model:                 2

Model name:            AMD Opteron(tm) Processor 6380

Stepping:              0

CPU MHz:               2500.065

BogoMIPS:              4999.42

Virtualization:        AMD-V

L1d cache:             16K

L1i cache:             64K

L2 cache:              2048K

L3 cache:              6144K

NUMA node0 CPU(s):     0-7

NUMA node1 CPU(s):     8-15

NUMA node2 CPU(s):     16-23

NUMA node3 CPU(s):     24-31

NUMA node4 CPU(s):     32-39

NUMA node5 CPU(s):     40-47

NUMA node6 CPU(s):     48-55

NUMA node7 CPU(s):     56-63

(Old software...)

jb12407@lmfdb5:~$ lsb_release -a

LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch

Distributor ID: Scientific

Description: Scientific Linux release 6.8 (Carbon)

Release: 6.8

Codename: Carbon

jb12407@lmfdb5:~$ uname -r

2.6.32-573.3.1.el6.x86_64

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[Dima Pasechnik]

Most probably gcc version used to build Sage is also quite important...

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Jonathan Bober]

That's a good point. It looks like 5.1.0. I will try rebuilding from scratch with SAGE_INSTALL_GCC=yes, since that's easier than actually trying to figure out what's going on. (Also, it is past time for me to update gcc, since it looks like I can easily have 6.1.0 on this system.) I will report back in 90 minutes, unless I don't, in which case I'll report back in 10 to 24 hours.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

[Jonathan Bober]

Unfortunately, didn't work correctly. Running

SAGE_INSTALL_GCC=yes make

seems to do something wrong to gmp. e.g., while building GMP-ECM...

checking if gmp.h version and libgmp version are the same... (6.1.0/5.1.3) no

configure: error: 'gmp.h' and 'libgmp' have different versions, you have to reinstall GMP properly.

Error configuring GMP-ECM.

Is it possible that some environment variable I've set has messed something up?

Also, I ran make distclean instead of really starting from scratch. Is that relevant?

[Dima Pasechnik]

On Monday, September 26, 2016 at 12:06:44 AM UTC, Jonathan Bober wrote:

Unfortunately, didn't work correctly. Running

SAGE_INSTALL_GCC=yes make

seems to do something wrong to gmp. e.g., while building GMP-ECM...

checking if gmp.h version and libgmp version are the same... (6.1.0/5.1.3) no

configure: error: 'gmp.h' and 'libgmp' have different versions, you have to reinstall GMP properly.

Error configuring GMP-ECM.

Is it possible that some environment variable I've set has messed something up?

surely one can mess everything up with env. vars :-)

 

Also, I ran make distclean instead of really starting from scratch. Is that relevant?

make distclean should do the trick.

your error message seems to indicate that it was not completely cleaned.

I recall seeing that sometimes some git magic is needed, to really clean up...

http://stackoverflow.com/questions/61212/how-to-remove-local-untracked-files-from-the-current-git-branch

[Dima Pasechnik]

On Sunday, September 25, 2016 at 10:48:51 PM UTC, Jonathan Bober wrote:

That's a good point. It looks like 5.1.0. I will try rebuilding from scratch with SAGE_INSTALL_GCC=yes, since that's easier than actually trying to figure out what's going on.

it might well be that 5.1 cannot build Sage's gcc (4.9.3), as it's too new...

So you'd need to downgrade system gcc if you really want to use Sage's gcc.

I'd rather install gcc 5.4 or 6.1 on the system.

[Jonathan Bober]

I recompiled with gcc 6.1.0, and get the same segfault. I did a ./sage -i gdb to get a better crash report, which is attached. I don't know if it is useful. Also, it mentions some gcc 5.1.0 paths, which seems odd. I don't know if that indicates that something is broken on my end.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

[Jonathan Bober]

On Mon, Sep 26, 2016 at 2:00 AM, Dima Pasechnik <dim...@gmail.com> wrote:

surely one can mess everything up with env. vars :-)

Yes, of course, I should have been more specific. I mean 'standard' environment variables (which users like me might use in wrong or 'hackish' ways).  e.g., something like

module add gcc-6.1.0-x86_64

export PATH=$HOME/bin:/data/local/bin:/opt/gcc-6.1.0/bin:$PATH

export LD_LIBRARY_PATH=$HOME/lib:/data/local/lib:$LD_LIBRARY_PATH

export LIBRARY_PATH=$HOME/lib:/data/local/lib

export C_INCLUDE_PATH=$HOME/include:/data/local/include

export CPLUS_INCLUDE_PATH=$HOME/include:/data/local/include

export LD_RUN_PATH=$HOME/lib:/data/local/lib

export SAGE_ATLAS_LIB=/usr/lib64/atlas-sse3/

export STATIC_LIB_DIR=/data/local/lib/

(Actually, I unset SAGE_ATLAS_LIB before the latest build, since the current development branch has switched to OpenBLAS. (I think I want to say hooray about that, but will at least wait until it doesn't segfault.))

How much attention (if any) does Sage pay to these environment variables?

[Dima Pasechnik]

On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober wrote:

I recompiled with gcc 6.1.0, and get the same segfault. I did a ./sage -i gdb to get a better crash report, which is attached. I don't know if it is useful. Also, it mentions some gcc 5.1.0 paths, which seems odd. I don't know if that indicates that something is broken on my end.

I am mostly guessing, but mentioning gcc 5.1.0 in the log does sound to me as if your toolchain might be broken after update to gcc 6.1 (perhaps it's debugging versions of libs...)

(and I use gcc 6.2.1 on my system with working openblas update)

[Jonathan Bober]

On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik <dim...@gmail.com> wrote:

On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober wrote:

I recompiled with gcc 6.1.0, and get the same segfault. I did a ./sage -i gdb to get a better crash report, which is attached. I don't know if it is useful. Also, it mentions some gcc 5.1.0 paths, which seems odd. I don't know if that indicates that something is broken on my end.

I am mostly guessing, but mentioning gcc 5.1.0 in the log does sound to me as if your toolchain might be broken after update to gcc 6.1 (perhaps it's debugging versions of libs...)

No, I think I was confused and used the wrong installation of sage to produce that crash report. Maybe I typed sage instead of ./sage. The correct crash report is attached now.

[Jean-Pierre Flori]

The backtrace does not say much to me...
Maybe you could try to update openblas? our version is already outdated.
And hopefully this might have been fixed in a newer version (though I did not find anything looking very related after a few google searches).
Just download the latest openblas  tarball into upstream, edit build/pkgs/openblas/package-version.txt to reflect the version change and run sage --package fix-checksum openblas to update the checksum.

[Jonathan Bober]

I now seem to have built a version that doesn't segfault on this, without intentionally changing anything. So I don't know what is going on. I may try another build from scratch, just for the sake of my sanity.

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

[leif]

Jean-Pierre Flori wrote:
>
>
> On Monday, September 26, 2016 at 11:47:00 AM UTC+2, Jonathan Bober wrote:
>
> On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik <dim...@gmail.com
> <javascript:>> wrote:
>
>
>
> On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober
> wrote:
>
> I recompiled with gcc 6.1.0, and get the same segfault. I
> did a ./sage -i gdb to get a better crash report, which is
> attached. I don't know if it is useful. Also, it mentions
> some gcc 5.1.0 paths, which seems odd. I don't know if that
> indicates that something is broken on my end.

If in doubt, try building with '-mno-xop' in CFLAGS. AFAICT, *every*
GCC version supporting Bulldozer+ is broken w.r.t. mixing AVX and XOP
instructions (at higher optimization levels). (I haven't tried 6.x yet
though IIRC; GMP-ECM 6.4 built with '-march=native -O3' was an example
exposing this in the past, 7.x no longer does.)


-leif

[Jonathan Bober]

On Mon, Sep 26, 2016 at 1:50 PM, leif <not.r...@online.de> wrote:

Jean-Pierre Flori wrote:
>
>
> On Monday, September 26, 2016 at 11:47:00 AM UTC+2, Jonathan Bober wrote:
>
>     On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik <dim...@gmail.com
>     <javascript:>> wrote:
>
>
>
>         On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober
>         wrote:
>
>             I recompiled with gcc 6.1.0, and get the same segfault. I
>             did a ./sage -i gdb to get a better crash report, which is
>             attached. I don't know if it is useful. Also, it mentions
>             some gcc 5.1.0 paths, which seems odd. I don't know if that
>             indicates that something is broken on my end.

If in doubt, try building with '-mno-xop' in CFLAGS.  AFAICT, *every*
GCC version supporting Bulldozer+ is broken w.r.t. mixing AVX and XOP
instructions (at higher optimization levels).  (I haven't tried 6.x yet
though IIRC; GMP-ECM 6.4 built with '-march=native -O3' was an example
exposing this in the past, 7.x no longer does.)

I can just set the CFLAGS variable, and Sage will use it (or add to it)?

Meanwhile, rebuilding produced the error again. By rebuilding from scratch, I really mean the following set of commands (which has some output and irrelevant commands omitted, but is otherwise an actual log of what I typed in, and not just a reproduction from my faulty memory).

jb12407@lmfdb5:~/tmp$ rm -rf sage

jb12407@lmfdb5:~/tmp$ git clone g...@github.com:sagemath/sage.git

jb12407@lmfdb5:~/tmp$ cd sage

jb12407@lmfdb5:~/tmp/sage$ gcc -v

Using built-in specs.

COLLECT_GCC=/opt/gcc-6.1.0/bin/gcc

COLLECT_LTO_WRAPPER=/opt/gcc-6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper

Target: x86_64-pc-linux-gnu

Configured with: ../source-links/configure --prefix=/opt/gcc-6.1.0 --enable-languages=c,c++,fortran

Thread model: posix

gcc version 6.1.0 (GCC) 

jb12407@lmfdb5:~/tmp/sage$ git checkout develop

jb12407@lmfdb5:~/tmp/sage$ export MAKE='make -j40'

jb12407@lmfdb5:~/tmp/sage$ unset SAGE_ATLAS_LIB

jb12407@lmfdb5:~/tmp/sage$ make

(This terminates in an error building the documentation because of memory overcommit issues, but it builds everything else fine. That's a nice side effect if the overcommit problems, IMHO ;)

Finally...

jb12407@lmfdb5:~/tmp/sage$ ./sage

┌────────────────────────────────────────────────────────────────────┐

│ SageMath version 7.4.beta6, Release Date: 2016-09-24               │

│ Type "notebook()" for the browser-based notebook interface.        │

│ Type "help()" for help.                                            │

└────────────────────────────────────────────────────────────────────┘

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

┃ Warning: this is a prerelease version, and it may be unstable.     ┃

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

This looks like the first time you are running Sage.

Updating various hardcoded paths...

(Please wait at most a few minutes.)

DO NOT INTERRUPT THIS.

Done updating paths.

sage: m = random_matrix(RDF,500)

sage: e = m.eigenvalues()

BOOM!

[Martin R]

On my computer, 7.4.beta6 doesn't seem to compile openblas successfully either.  After make distclean and make I get an error (log attached).

real 135m22.614s

user 407m51.656s

sys 21m22.276s

***************************************************************

Error building Sage.

The following package(s) may have failed to build (not necessarily

during this run of 'make all'):

* package: openblas-0.2.15

  log file: /home/martin/sage-develop/logs/pkgs/openblas-0.2.15.log

  build directory: /home/martin/sage-develop/local/var/tmp/sage/build/openblas-0.2.15

[Martin R]

I forgot:

martin@Martin-Laptop:~/sage-develop$ lscpu 

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                4

On-line CPU(s) list:   0-3

Thread(s) pro Kern:    1

Kern(e) pro Socket:    4

Socket(s):             1

NUMA-Knoten:           1

Anbieterkennung:       GenuineIntel

Prozessorfamilie:      6

Modell:                55

Model name:            Intel(R) Celeron(R) CPU  N2940  @ 1.83GHz

Stepping:              8

CPU MHz:               535.104

CPU max MHz:           2249,1001

CPU min MHz:           499,8000

BogoMIPS:              3660.80

Virtualisierung:       VT-x

L1d Cache:             24K

L1i Cache:             32K

L2 Cache:              1024K

NUMA node0 CPU(s):     0-3

[Jonathan Bober]

I've rebuilt again from scratch, twice. Once after clearing all my possibly questionable environment variables (except for LD_LIBRARY_PATH, since that is needed for gcc-6.1.0, as set by module add gcc-6.1.0 for me). The second time I did "CFLAGS=-mno-xop make". I can see that flag took effect by examining the OpenBLAS build log, for example.

Question: Does SAGE_ATLAS_LIB have any effect on the develop branch? I don't know what I did differently to get a build that doesn't segfault.

[Jonathan Bober]

I suspect that perhaps the copy I have the works is working because I built it as sage 7.3 at some point with SAGE_ATLAS_LIB set and then rebuilt it on the develop branch, which didn't get rid of the atlas symlinks that were already setup. So maybe it isn't actually using openBLAS.

[Martin R]

I just tried make after saying "export TARGET=P2".  Doing so, openblas starts to build but fails after a while saying

ar: sgemm_kernel.o: No such file or directory

../Makefile.tail:40: recipe for target 'libs' failed

make[4]: *** [libs] Error 1

make[4]: Leaving directory '/home/martin/sage-develop/local/var/tmp/sage/build/openblas-0.2.15/src/kernel'

Makefile:143: recipe for target 'libs' failed

make[3]: *** [libs] Error 1

make[3]: Leaving directory '/home/martin/sage-develop/local/var/tmp/sage/build/openblas-0.2.15/src'

Error building OpenBLAS

Is there a quick fix?

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Michael Orlitzky]

On 09/26/2016 03:03 PM, 'Martin R' via sage-devel wrote:
>
> Is there a quick fix?
>

To get something usable, try

./configure --with-blas=atlas

before running "make". I had a similar problem:

https://trac.sagemath.org/ticket/21561

[Martin R]

Thanks, now (and for the next few hours :-) trying...

[Jean-Pierre Flori]

On Monday, September 26, 2016 at 8:42:26 PM UTC+2, Jonathan Bober wrote:

I suspect that perhaps the copy I have the works is working because I built it as sage 7.3 at some point with SAGE_ATLAS_LIB set and then rebuilt it on the develop branch, which didn't get rid of the atlas symlinks that were already setup. So maybe it isn't actually using openBLAS.

SAGE_ATLAS_LIB is just used for ATLAS, not OpenBlas.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Jean-Pierre Flori]

On Monday, September 26, 2016 at 9:06:17 PM UTC+2, Michael Orlitzky wrote:

On 09/26/2016 03:03 PM, 'Martin R' via sage-devel wrote:
>
> Is there a quick fix?
>

To get something usable, try

  ./configure --with-blas=atlas

before running "make". I had a similar problem:

Yes, this should switch back to atlas.
Then you have to be patient enough for atlas to build :)

  https://trac.sagemath.org/ticket/21561

[Jonathan Bober]

On Mon, Sep 26, 2016 at 10:10 PM, Jean-Pierre Flori <jpf...@gmail.com> wrote:

I suspect that perhaps the copy I have the works is working because I built it as sage 7.3 at some point with SAGE_ATLAS_LIB set and then rebuilt it on the develop branch, which didn't get rid of the atlas symlinks that were already setup. So maybe it isn't actually using openBLAS.

SAGE_ATLAS_LIB is just used for ATLAS, not OpenBlas. 

1. So does that mean that on a clean build of the current development branch (or a recent enough beta) SAGE_ATLAS_LIB has, by default, no effect?

2. Either way, I suspect that doesn't necessarily mean that nothing strange happens if I build Sage 7.3 (with SAGE_ATLAS_LIB set) and then do a 'git checkout develop', then build again without first doing a distclean.

[Jean-Pierre Flori]

On Monday, September 26, 2016 at 11:23:49 PM UTC+2, Jonathan Bober wrote:

On Mon, Sep 26, 2016 at 10:10 PM, Jean-Pierre Flori <jpf...@gmail.com> wrote:

I suspect that perhaps the copy I have the works is working because I built it as sage 7.3 at some point with SAGE_ATLAS_LIB set and then rebuilt it on the develop branch, which didn't get rid of the atlas symlinks that were already setup. So maybe it isn't actually using openBLAS.

SAGE_ATLAS_LIB is just used for ATLAS, not OpenBlas. 

1. So does that mean that on a clean build of the current development branch (or a recent enough beta) SAGE_ATLAS_LIB has, by default, no effect?

Yes.

2. Either way, I suspect that doesn't necessarily mean that nothing strange happens if I build Sage 7.3 (with SAGE_ATLAS_LIB set) and then do a 'git checkout develop', then build again without first doing a distclean.

 Yes.
I'm not exactly in what situation you end up when going this way because:
* at 7.3, you ran configure/make which set up Atlas as the blas provider, build it and link everything to it
* when checking out develop openblas became the default but I'm not sure this actually changed anything if configure was not run again before make... the best way to now for sure is to see if libraries depending on blas got rebuilt (in particular atlas and openblas do not provide binary compatible libraries, you have to link to libs with different names)
Maybe Jeroen or Volker have a better idea of what situation you end up in.

But if you run "make distclean" then you can be sure that openblas will be built and linked to...

[Jonathan Bober]

I got around to trying the latest OpenBLAS as Jean-Pierre Flori suggested, and the segfaults went away. (And all tests pass.) I guess that from my perspective this means I should open an "update to OpenBLAS 0.2.19" ticket. Or maybe it should be an "Update OpenBLAS to some working version" ticket. I don't know much about OpenBLAS, so I don't really know if 2.19 will work for me but will be broken for someone else.

(OpenBLAS 2.15, the current version, is from 11 months ago.)

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

[leif]

Jonathan Bober wrote:
> I got around to trying the latest OpenBLAS as Jean-Pierre Flori
> suggested, and the segfaults went away. (And all tests pass.) I guess
> that from my perspective this means I should open an "update to OpenBLAS
> 0.2.19" ticket. Or maybe it should be an "Update OpenBLAS to some
> working version" ticket. I don't know much about OpenBLAS, so I don't
> really know if 2.19 will work for me but will be broken for someone else.

Probably not a bad idea.

For me, building R currently segfaults in Sage 7.4.beta6 (with OpenBLAS)
while the same builds [with ATLAS] in Sage 7.3, both on a Piledriver
with FSF GCC 6.2 (configured to generate native code by default; without
any *FLAGS set by me).

OpenBLAS' testsuite though passes, and I recall to have seen similar in
building R in the past (quite long ago), but OTOH have no idea how I
fixed or worked around that previously.


I also noticed Sage's OpenBLAS package ("again") uselessly depends on
Sage's Python. And OpenBLAS' "configure" step doesn't seem to report
anything useful...


-leif