misc/cgo/testsanitizers: Segmentation fault using GCC 6.1.1 (and Clang 3.8.1)

[mewmew]

1. What version of Go are you using (go version)?

go version devel +219ca60 Sat Aug 6 19:30:57 2016 +0000 linux/amd64

Clang and GCC versions:

u@x1 ~/g/src> clang --version
clang version 3.8.1 (tags/RELEASE_381/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

u@x1 ~/g/src> gcc --version
gcc (GCC) 6.1.1 20160802
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

1. What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/u/goget:/home/u/Desktop/go"
GORACE=""
GOROOT="/home/u/go"
GOTOOLDIR="/home/u/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build846316599=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?

Execute ./all.bash.

1. What did you expect to see?

All tests passed.

1. What did you see instead?

Segmentation faults were reported from the memory sanitizer test cases.

##### ../misc/cgo/testsanitizers
signal: segmentation fault (core dumped)
FAIL: msan
signal: segmentation fault (core dumped)
FAIL: msan2 with -fsanitize=memory
signal: segmentation fault (core dumped)
FAIL: msan2
signal: segmentation fault (core dumped)
FAIL: msan3
signal: segmentation fault (core dumped)
FAIL: msan4
2016/08/08 14:48:46 Failed: exit status 1

The core dumps don't seem to be revealing too much.

u@x1 ~/g/src> coredumpctl gdb 30958
           PID: 30958 (msan_fail)
           UID: 1000 (u)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Mon 2016-08-08 14:37:38 CEST (14min ago)
  Command Line: /tmp/go-build818063084/command-line-arguments/_obj/exe/msan_fail
    Executable: /tmp/go-build818063084/command-line-arguments/_obj/exe/msan_fail
 Control Group: /user.slice/user-1000.slice/session-c1.scope
          Unit: session-c1.scope
         Slice: user-1000.slice
       Session: c1
     Owner UID: 1000 (u)
       Boot ID: 457313786431498991c0d5c32a000f52
    Machine ID: 8be6e9b1337f4bf3864e9184c2ef52c8
      Hostname: x1
      Coredump: /var/lib/systemd/coredump/core.msan_fail.1000.457313786431498991c0d5c32a000f52.30958.1470659858000000000000.lz4
       Message: Process 30958 (msan_fail) of user 1000 dumped core.

                Stack trace of thread 30958:
                #0  0x000000000041ee95 n/a (/tmp/go-build818063084/command-line-arguments/_obj/exe/msan_fail)

GNU gdb (GDB) 7.11.1
Copyright (C) 2016 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
/tmp/go-build818063084/command-line-arguments/_obj/exe/msan_fail: No such file or directory.
[New LWP 30958]
Core was generated by `/tmp/go-build818063084/command-line-arguments/_obj/exe/msan_fail'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000041ee95 in ?? ()
(gdb) bt
#0  0x000000000041ee95 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb) q

Any idea on how to investigate this further?

[mewmew]

Note, CC was unset, so the GCC compiler should have been used by ./all.bash. Setting CC=clang resulted in #15405.

[ianlancetaylor]

What version of GNU/Linux are you running?

Note that misc/cgo/testsanitizers/test.bash will use clang if it exists. I don't know why setting CC=clang would make a difference.

[ianlancetaylor]

Oh, I see, CC=clang causes a different test to fail.

[mewmew]

What version of GNU/Linux are you running?

Arch Linux

u@x1 ~> uname -a
Linux x1 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux

[ianlancetaylor]

Can you test whether clang -fsanitize=memory works at all on your system? Just try compiling some C program with the -fsanitize=memory option and see whether it runs correctly.

[mewmew]

You seem to be right, something is wrong with -fsanitize=memory in general on my system.

u@x1 ~> cat a.c
int main() {
    return 0;
}
u@x1 ~> clang -fsanitize=memory -o a a.c
u@x1 ~> ./a
fish: “./a” terminated by signal SIGSEGV (Address boundary error)

u@x1 ~> coredumpctl gdb 3999
           PID: 3999 (a)
           UID: 1000 (u)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Mon 2016-08-08 22:06:24 CEST (20s ago)
  Command Line: ./a
    Executable: /home/u/a
 Control Group: /user.slice/user-1000.slice/session-c1.scope
          Unit: session-c1.scope
         Slice: user-1000.slice
       Session: c1
     Owner UID: 1000 (u)
       Boot ID: 568a956a6d1d44b0ac0da6d1d8725fb1
    Machine ID: 8be6e9b1337f4bf3864e9184c2ef52c8
      Hostname: x1
      Coredump: /var/lib/systemd/coredump/core.a.1000.568a956a6d1d44b0ac0da6d1d8725fb1.3999.1470686784000000000000.lz4
       Message: Process 3999 (a) of user 1000 dumped core.

                Stack trace of thread 3999:
                #0  0x000000000041e425 _ZN11__sanitizer20SizeClassAllocator64ILm123145302310912ELm8796093022208ELm8ENS_12SizeClassMapILm17ELm128ELm16EEEN6__msan20MsanMapUnmapCallbackEE13AllocateBatchEPNS_14AllocatorStatsEPNS_28SizeClassAllocatorLocalCacheIS5_EEm (a)
                #1  0x000000000041e4e7 _ZN11__sanitizer28SizeClassAllocatorLocalCacheINS_20SizeClassAllocator64ILm123145302310912ELm8796093022208ELm8ENS_12SizeClassMapILm17ELm128ELm16EEEN6__msan20MsanMapUnmapCallbackEEEE6RefillEPS6_m (a)
                #2  0x000000000041da41 _ZN6__msan14MsanReallocateEPN11__sanitizer10StackTraceEPvmmb (a)
                #3  0x000000000041f96e __interceptor_malloc (a)
                #4  0x00007ff3af9df181 _dl_signal_error (ld-linux-x86-64.so.2)
                #5  0x00007ff3af9df343 _dl_signal_cerror (ld-linux-x86-64.so.2)
                #6  0x00007ff3af9da0de _dl_lookup_symbol_x (ld-linux-x86-64.so.2)
                #7  0x00007ff3aec0ddf1 do_sym (libc.so.6)
                #8  0x00007ff3af0a4034 n/a (libdl.so.2)
                #9  0x00007ff3af9df3c4 _dl_catch_error (ld-linux-x86-64.so.2)
                #10 0x00007ff3af0a4541 n/a (libdl.so.2)
                #11 0x00007ff3af0a4088 dlsym (libdl.so.2)
                #12 0x0000000000465c7c _ZN14__interception22GetRealFunctionAddressEPKcPmmm (a)
                #13 0x000000000044f655 _ZN6__msan22InitializeInterceptorsEv (a)
                #14 0x000000000041a375 __msan_init (a)
                #15 0x0000000000485c56 msan.module_ctor (a)
                #16 0x0000000000485cad __libc_csu_init (a)
                #17 0x00007ff3aeb0f260 __libc_start_main (libc.so.6)
                #18 0x0000000000418bba _start (a)

GNU gdb (GDB) 7.11.1
Copyright (C) 2016 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/u/a...(no debugging symbols found)...done.
[New LWP 3999]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `./a'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000041e425 in __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch(__sanitizer::AllocatorStats*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >*, unsigned long) ()

Sorry for the noice, this should have been reported upstream I guess. Either to Arch or Clang.

[mewmew]

Closing this issue as it seems to be a problem with my system in general rather than Go.

[ianlancetaylor]

Thanks for following up. Let us know if you find out what the problem is--perhaps we can simply skip the test on systems where it won't work.

[omac777]

I'm on ArchLinux updated yesterday:
Linux blah 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64 GNU/Linux

Here are the package versions related to this:
core/gcc 6.1.1-5 (base-devel) [installed]
The GNU Compiler Collection - C and C++ frontends

extra/clang 3.8.1-1 [installed]
C language family frontend for LLVM

extra/llvm 3.8.1-1 [installed]
Low Level Virtual Machine

extra/llvm-libs 3.8.1-1 [installed]
Low Level Virtual Machine (runtime libraries)

extra/lldb 3.8.1-1 [installed]
Next generation, high-performance debugger

extra/clang 3.8.1-1 [installed]
C language family frontend for LLVM

extra/clang-tools-extra 3.8.1-1 [installed]
Extra tools built using clang's tooling APIs

git describe
fatal: No annotated tags can describe '1e933ed7c091bd8e077ffd123234af10a69e3978'.
However, there were unannotated tags: try --tags.
git status
HEAD detached at go1.7rc6
nothing to commit, working tree clean

GOROOT_BOOTSTRAP=/root/SQstuff/go1.7rc5 ./all.bash

../misc/cgo/testsanitizers

signal: segmentation fault (core dumped)
FAIL: msan
signal: segmentation fault (core dumped)
FAIL: msan2 with -fsanitize=memory
signal: segmentation fault (core dumped)
FAIL: msan2
signal: segmentation fault (core dumped)
FAIL: msan3
signal: segmentation fault (core dumped)
FAIL: msan4
2016/08/11 11:18:25 Failed: exit status 1

../misc/cgo/errors

../misc/cgo/testsigfwd

../test/bench/go1

testing: warning: no tests to run
PASS
ok _/root/SQstuff/go1.7rc6/test/bench/go1 2.303s

../test

skipped due to earlier error
skipped due to earlier error
skipped due to earlier error
skipped due to earlier error
skipped due to earlier error

API check

skipped due to earlier error
2016/08/11 11:18:25 FAILED

go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/SQstuff/Code"
GORACE=""
GOROOT="/root/SQstuff/go1.7rc5"
GOTOOLDIR="/root/SQstuff/go1.7rc5/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build835280077=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

I did notice the CC="gcc" because I only recently installed "clang".
THIS DOESNT WORK: CC=/usr/bin/clang GOROOT_BOOTSTRAP=/root/SQstuff/go1.7rc5 ./all.bash

THIS WORKS:
CC=/usr/bin/clang GOROOT_BOOTSTRAP=/root/SQstuff/go1.7rc5 ./make.bash
That compiled successfully with clang.

[mewmew]

@omac777 Would you mind verifying if you can compile any program on your system with clang -fsanitize=memory?

From #16636 (comment)

u@x1 ~> cat a.c
int main() {
    return 0;
}
u@x1 ~> clang -fsanitize=memory -o a a.c
u@x1 ~> ./a
fish: “./a” terminated by signal SIGSEGV (Address boundary error)

[depado]

@mewmew I got the same issue, and I can't seem to compile with -fsanitize=memory (same error as you, also on Archlinux)
But the trick of @omac777 worked for me.