https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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/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/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/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
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
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.
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
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.
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)
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Stephen Kim changed:
What|Removed |Added
CC||stephen.kim at oracle dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
14 matches
Mail list logo
