Bus error while running tests on OpenBSD

[ararslan]

First I should note that I had to install Bash (it isn't installed by default) and make the following change in order to build on OpenBSD:

--- a/build/flatten-headers.py
+++ a/build/flatten-headers.py
@@ -1,3 +1,3 @@
-#!/usr/bin/env python
+#!/usr/bin/env python2.7
 #
 # BLIS

Now, to configure, build, and test BLIS on OpenBSD 6.2, I ran

./configure --enable-blas --enable-cblas --enable-shared CC=cc auto
gmake
gmake test

which produced the following error:

Running test_libblis.x with output redirected to 'output.testsuite'
bash: line 2: 34747 Bus error               (core dumped) ./test_libblis.x -g ./testsuite/input.general -o ./testsuite/input.operations > output.testsuite
gmake: *** [Makefile:730: testsuite-run] Error 138

I read the core dump file with GDB. Here's the backtrace:

#0  0x00000f389fd72d75 in .SGENSTORED () from /home/alex/Projects/blis/test_libblis.x
#1  0x00000f389fd592d3 in bli_gemm_ukernel () from /home/alex/Projects/blis/test_libblis.x
#2  0x00000f389fd07a23 in libblis_test_gemm_ukr_experiment ()
   from /home/alex/Projects/blis/test_libblis.x
#3  0x00000f389fd10f35 in libblis_test_op_driver () from /home/alex/Projects/blis/test_libblis.x
#4  0x00000f389fd075e1 in libblis_test_gemm_ukr () from /home/alex/Projects/blis/test_libblis.x
#5 0x00000f389fd0d200 in main () from /home/alex/Projects/blis/test_libblis.x

The full configuration and build log is here: https://gist.github.com/ararslan/94a109f525423d28f212a0aa69163827.

[devinamatthews]

2 Qs:

1. Does python -> python2 work instead of python2.7?
2. What is the problem that led to needing bash? We try to be POSIX-compliant. gmake is another issue...

[devinamatthews]

Also, can you please share your HW details and specific git commit used.

[ararslan]

Answers to your question:

1. For some reason OpenBSD doesn't symlink python2 like other platforms, so /usr/bin/env python2 similarly doesn't work. Your guess is as good as mine as to why they chose to do this.
2. The shell scripts here are written as /usr/bin/env bash, which tries to use bash. If the scripts are POSIX-compliant, perhaps the shebang lines should just be /bin/sh?

Git commit: 4b72a46

System: OpenBSD 6.2 x86-64 running in VirtualBox on Intel Core i7-7700 CPU @ 3.60GHz with 4 cores dedicated to the VM.

Is that hardware description sufficient, or is there any other information you need?

[ararslan]

Regarding gmake, that's no problem, that's just how BSDs refer to GNU Make, since make points to the incompatible BSD Make. As long as the Makefiles here are written to use $(MAKE) when calling Make from a Makefile, all is well.

[fgvanzee]

@ararslan The first few lines of your logfile:

configure: using 'cc' compiler.
configure: found cc version 4.2.1 (maj: 4, min: 2, rev: 1).

My guess is that the original sin here is that configure is picking up your default gcc 4.2.1 installation. Would you mind re-running configure and make in light of the commits for #201 to see if this is still a problem? If we can get configure to pick up cc (which you point out is actually a link to clang on OpenBSD) then hopefully this issue resolves itself.

[gaming-hacker]

or launch a bash shell without default env

[fgvanzee]

@ararslan What configuration are you targeting?

I just realized that the compiler selected by configure isn't actually being communicated to make. This sounds like a totally bone-headed mistake, but it is only half as bone-headed as it seems since there is some history behind this relating to why configure is querying the compiler at all.

The point is, currently, even if configure chooses the right compiler from its search list, make isn't actually using it. Unless CC is set, the compiler used by make is determined by the make_defs.mk file in the appropriate config sub-directory. I will open another issue for this.

[ararslan]

My guess is that the original sin here is that configure is picking up your default gcc 4.2.1 installation.

That's quite bizarre. In my configuration step I'm explicitly specifying CC=cc, which I assumed was safe, because:

$ cc --version
OpenBSD clang version 4.0.0 (tags/RELEASE_400/final) (based on LLVM 4.0.0)
Target: amd64-unknown-openbsd6.2
Thread model: posix
InstalledDir: /usr/bin

Interestingly, if I specify CC=clang, I also get configure telling me that it found version 4.2.1.

What configuration are you targeting?

auto

[ararslan]

The plot thickens... based on current master,

$ ./configure --enable-blas --enable-cblas --enable-shared auto
configure: detected OpenBSD kernel version 6.2.
configure: compiler search list is: cc clang gcc.
configure: using 'cc' compiler.
configure: found cc version 4.2.1 (maj: 4, min: 2, rev: 1).
...
$ gmake
Generating monolithic blis.h........................................................................................................................................................................................................................................................................................................................................................................................................................................................
Generated include/sandybridge/blis.h
Compiling obj/sandybridge/config/sandybridge/bli_cntx_init_sandybridge.o ('sandybridge' CFLAGS for config code)
Compiling obj/sandybridge/kernels/sandybridge/3/bli_gemm_sandybridge_asm_d8x4.o ('sandybridge' CFLAGS for kernels)
cc1: error: unrecognized command line option "-mavx"
kernels/sandybridge/3/bli_gemm_sandybridge_asm_d8x4.c:1: error: bad value (corei7-avx) for -march= switch
compilation terminated due to -Wfatal-errors.
gmake: *** [Makefile:563: obj/sandybridge/kernels/sandybridge/3/bli_gemm_sandybridge_asm_d8x4.o] Error 1

Full log: https://gist.github.com/ararslan/af959e918dce3f93844edd069173db19

So just running gmake on OpenBSD no longer works...

[fgvanzee]

I've opened #208 . It will hopefully bring us closer to resolution on this.

Not sure what to make of the sudden gmake brokenness, though. :-\

[fgvanzee]

Give ad67dc4 a try. This commit should actually compile with the same compiler that was selected by configure regardless of whether that compiler was selected because CC was set, or because it was found in the compiler search list for the detected OS.

[fgvanzee]

@ararslan As mentioned in #204, recent commits 12dfa95 and 2e31dd7 may further increase the odds that this issue is resolved. Let us know how it goes.

[ararslan]

This has indeed been fixed! All tests pass without errors on OpenBSD. Thanks!

[fgvanzee]

Great to hear. Thanks for the update, Alex.