https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798
Bug ID: 65798
Summary: runtime.Caller returns ok=true when return data is
invalid
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target: ppc64le, x86_64, s390x
Created attachment 35347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35347&action=edit
Don't return ok=true from runtime.Caller if the pc is 0 or the filename has 0
len.
This came from a user trying to build Docker on Fedora 22 using gccgo. The
they found when calling runtime.Caller, the return value for ok could be true
even though the other returned values could be invalid. Because ok was true
they assumed the data was valid and tried to use those return values from
runtime.Caller to pass onto runtime.FuncForPC which then resulted in the signal
11 displayed below.
The failure occurs on every platform they tried to use with gccgo. Here is the
original information:
------------------------------------
Description of problem:
docker using gcc-go crashes
Version-Release number of selected component (if applicable):
gcc-5.0.1-0.1.fc22
How reproducible:
Always(reproduced on x86_64, ppc64le, s390x, but expecting ppc64 too)
Steps to Reproduce:
1.install docker from https://repos.fedorapeople.org/repos/jcajka/docker-gccgo/
(ppc64(le), s390x) or https://copr.fedoraproject.org/coprs/jcajka/docker-gccgo/
(x86_64)
2.systemctl start docker
3.mkdir /root/dir
4.chcon -Rt svirt_sandbox_file_t /root/dir/ (just in case)
5.1 for x86:
docker run fedora -itv /root/dir/:/root/dir/ /bin/bash
5.2 for ppc64(le),s390x(replace arch in docker.io/jcajka/fedora22-...):
docker run docker.io/jcajka/fedora22-ppc64 -itv /root/dir/:/root/dir/
/bin/bash
Actual results
on ppc64le/x86:
docker run docker.io/jcajka/fedora22-ppc64le -itv /root/dir/:/root/dir/
/bin/bash
panic: runtime error: invalid memory address or nil pointer dereference
on ppc64le: [signal 0xb code=0x1 addr=0x8]
on x86_64: [signal 0xb code=0x1 addr=0x0]
goroutine 16 [running]:
github_com_docker_libcontainer_stacktrace.NewFrame
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/stacktrace/frame.go:12
github_com_docker_libcontainer_stacktrace.Capture
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/stacktrace/capture.go:18
libcontainer.newSystemError
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/generic_error.go:48
libcontainer.$nested4
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/factory_linux.go:212
github_com_docker_libcontainer.StartInitialization.pN43_github_com_docker_libcontainer.LinuxFactory
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/factory_linux.go:224
native.initializer
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/_build/src/github.com/docker/docker/daemon/execdriver/native/init.go:35
github_com_docker_docker_pkg_reexec.Init
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/_build/src/github.com/docker/docker/pkg/reexec/reexec.go:26
main.main
/builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/docker/docker.go:29
goroutine 18 [finalizer wait]:
created by runtime_createfing
../../../libgo/runtime/mgc0.c:2572
goroutine 19 [syscall]:
goroutine in C code; stack unavailable
created by os_signal..import
../../../libgo/go/os/signal/signal_unix.go:25
Expected results:
docker run docker.io/jcajka/fedora22-s390x -itv /root/dir/:/root/dir/ /bin/bash
FATA[0000] Error response from daemon: Cannot start container
fb6ed2f3efd57fa07ddf5c4d8576408d0f4cb95fe645a335063f7bed014a0654: [8] System
error: exec: "-itv": executable file not found in $PATH
Additional info:
Crash seems to be triggered by creating new Frame using invalid
pc/filename/line in libcontainer(seen this crash from time to time, but haven't
got reliable reproducer, until now). As libgo's runtime.Caller(capture.go:14)
returns seemingly invalid data(0,"",0) later used in
runtime.FuncForPC/parseFunctionName(frame.go). This could be workaround by
extending/fixing check in capture.go:15, but I think that runtime.Caller
shouldn't return ok state when returned data seems invalid. Patch in attachment
prevents this crash.
----------------------
I'm attaching their suggested patch.
