[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Ian Lance Taylor --- This should now be fixed. I filed the general issue of syscall.Syscall as https://golang.org/issue/26183.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #13 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jul 2 16:29:24 2018 New Revision: 262315 URL: https://gcc.gnu.org/viewcvs?rev=262315=gcc=rev Log: PR go/86331 os: check return value as well as error from waitid https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it is possible for syscall.Syscall6 to return a non-zero errno value even if no error occurs. That is a problem in general, but this fix will let us work around the general problem for the specific case of calling waitid. Reviewed-on: https://go-review.googlesource.com/121595 Modified: branches/gcc-7-branch/libgo/go/os/wait_waitid.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #12 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jul 2 16:28:58 2018 New Revision: 262314 URL: https://gcc.gnu.org/viewcvs?rev=262314=gcc=rev Log: PR go/86331 os: check return value as well as error from waitid https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it is possible for syscall.Syscall6 to return a non-zero errno value even if no error occurs. That is a problem in general, but this fix will let us work around the general problem for the specific case of calling waitid. Reviewed-on: https://go-review.googlesource.com/121595 Modified: branches/gcc-8-branch/libgo/go/os/wait_waitid.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #11 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jul 2 16:28:43 2018 New Revision: 262313 URL: https://gcc.gnu.org/viewcvs?rev=262313=gcc=rev Log: PR go/86331 os: check return value as well as error from waitid https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it is possible for syscall.Syscall6 to return a non-zero errno value even if no error occurs. That is a problem in general, but this fix will let us work around the general problem for the specific case of calling waitid. Reviewed-on: https://go-review.googlesource.com/121595 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/os/wait_waitid.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #10 from Ian Lance Taylor --- Thanks. The documentation for the syscall function say that it only sets errno on failure, but I forgot about signal handlers. That is definitely a problem. Since there is no generic way to detect whether a system call failed, this may require libgo to provide assembly language versions of syscall.Syscall.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #9 from Andreas Schwab --- In general, the value of errno is undefined unless you know the previous system call failed. In this case the SIGCHLD signal handler has modified errno. This has nothing to do with VM or arm64 or whatever.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #8 from Stephen Kim --- After applying your patch, the issue seems to have gone away.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #7 from Ian Lance Taylor ---
To be clear, the problem is not that the go tool is failing to find its
subcommands. The problem is that the go tool thinks that the waitid system
call is returning an error. However, the strace shows that waitid is not
returning an error.
The code calls waitid via syscall.Syscall6 (libgo/go/os/wait_waitid.go). The
Syscall6 function (libgo/go/syscall/syscall_unix.go) sets errno to 0, calls the
C library syscall function, and then reads errno. If the errno value that it
reads is not 0, the program will think that the system call to waitid has
failed. At this point my best guess is that in some cases errno is being set
to ENOENT somehow. As far as I know this approach of setting errno to 0 and
checking it after the syscall is the only general way to tell whether a syscall
has failed.
I wonder if the fact that this is running in a VM could have something to do
with this. Perhaps something the VM is doing is sometimes causing the errno
value to change.
It's possible that this patch will work around the problem. Could you try this
to see if it helps? Thanks.
diff --git a/libgo/go/os/wait_waitid.go b/libgo/go/os/wait_waitid.go
index 5a62b27f..c2a34ff6 100644
--- a/libgo/go/os/wait_waitid.go
+++ b/libgo/go/os/wait_waitid.go
@@ -28,9 +28,12 @@ func (p *Process) blockUntilWaitable() (bool, error) {
// We don't care about the values it returns.
var siginfo [16]uint64
psig := [0]
- _, _, e := syscall.Syscall6(syscall.SYS_WAITID, _P_PID, uintptr(p.Pid),
uintptr(unsafe.Pointer(psig)), syscall.WEXITED|syscall.WNOWAIT, 0, 0)
+ r, _, e := syscall.Syscall6(syscall.SYS_WAITID, _P_PID, uintptr(p.Pid),
uintptr(unsafe.Pointer(psig)), syscall.WEXITED|syscall.WNOWAIT, 0, 0)
runtime.KeepAlive(p)
- if e != 0 {
+ // Check r as well as e because https://gcc.gnu.org/PR86331
+ // suggests that on arm64 systems in a VM checking only e is
+ // unreliable.
+ if r != 0 && e != 0 {
// waitid has been available since Linux 2.6.9, but
// reportedly is not available in Ubuntu on Windows.
// See issue 16610.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #6 from Ian Lance Taylor --- Thanks for the strace output. The stat(NULL) is coming from libgo/runtime/go-caller.c in the function __go_get_backtrace_state. It's a bug, but it's a different bug.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #5 from Andreas Schwab --- This looks suspicious, why is stat being called with NULL? [pid 30149] newfstatat(AT_FDCWD, NULL, [pid 30149] <... newfstatat resumed> 0xb0119b30, 0) = -1 EFAULT (Bad address)
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #4 from Stephen Kim --- Just in case, this system also includes Google's gc. With the gc, everything that fails with gccgo like this seems all fine. Thus, I think this problem might be in the top-level "go tool," which parses the command line and invokes the sub tools.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #3 from Stephen Kim --- Created attachment 44327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44327=edit strace -f go run hello.go strace -f go run hello.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Stephen Kim changed:
What|Removed |Added
CC||stephen.kim at oracle dot com
--- Comment #2 from Stephen Kim ---
First of all, the error occurs sometimes but not always.
What is being called "the error" is as follows. Go run hello.go (just say
"hello!" with fmt.Println) sometimes fails to find gccgo itself. However, go
build with a cgo invokation sometimes fails to find cgo and sometimes succeed
with cgo but failed to locate gccgo. I assume that other go commands that
invoke any other subtool would have similar issues but with different error
messages.
Here is the example of failure with go run hello.go:
[aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go
/home/aion1223/install/bin/gccgo: waitid: no such file or directory; output:
"Using built-in specs.\nCOLLECT_GCC=/home/aion1223/install/bin/gccgo\nTarget:
aarch64-unknown-linux-gnu\nConfigured with: ../configure
--enable-languages=c,c++,go --prefix=/home/aion1223/install\nThread model:
posix\ngcc version 9.0.0 20180627 (experimental) (GCC)
\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n
/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/go1 - -quiet
-dumpbase - -mlittle-endian \"-mabi=lp64\" -auxbase -
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../.. -o
/tmp/ccr66E5t.s\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian'
'-mabi=lp64'\n as -EL \"-mabi=lp64\" -o -.o
/tmp/ccr66E5t.s\nCOMPILER_PATH=/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/\nLIBRARY_PATH=/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../:/lib/:/usr/lib/\nCOLLECT_GCC_OPTIONS='-c'
'-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n"
Here are examples of failure with go build that requires cgo:
$ cat ce.go
package main
import "fmt"
/*
const unsigned long long int neg = (const unsigned long long int) -1;
*/
import "C"
func main() {
var i uint64
i = uint64(C.neg)
fmt.Println(i)
}
[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build421481847
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
# command-line-arguments
waitid: no such file or directory
[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build170944385
go tool cgo: waitid: no such file or directory
cgo version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental)
[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build774257621
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
gcc -I /home/aion1223 -fPIC -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -o ./_x001.o -c _cgo_export.c
gcc -I /home/aion1223 -fPIC -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -o ./_x002.o -c ce.cgo2.c
cd $WORK
gcc -fsplit-stack -c -x c - || true
cd /home/aion1223
gcc -Wall -g -I $WORK/b001/ -I ./install/pkg/include -o $WORK/b001/_cgo_defun.o
-D GOOS_linux -D GOARCH_arm64 -fdebug-prefix-map=$WORK=/tmp/go-build
-gno-record-gcc-switches -c $WORK/b001/_cgo_defun.c
cd $WORK
/home/aion1223/install/bin/gccgo -fgo-importcfg=/dev/null -c -x c - || true
cd /home/aion1223
./install/bin/gccgo -c -g -fdebug-prefix-map=$WORK=/tmp/go-build
-gno-record-gcc-switches -fgo-relative-import-path=_/home/aion1223 -o
$WORK/b001/_go_.o -I $WORK/b001/_importcfgroot_ $WORK/b001/_cgo_gotypes.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-27 Ever confirmed|0 |1 --- Comment #1 from Ian Lance Taylor --- I'm not clear: does the error "waitid: no such file or directory" happen randomly, or does it happen every time? It looks like calling the waitid system call is returning ENOENT. I don't know what that would happen. Can you attach the output of `strace -f` for a failing run? Thanks.
