Gccgo-produced binaries fail if working directory containins a directory with the same basename as the binary #6715
Labels
Comments
Interesting. Looks like a bug in the libbacktrace library. It needs to open the executable in order to read the debug info, and one of the approaches it tries is to open it by name. We need to avoid doing that, or to at least verify that doing so does in fact yield the executable. Status changed to Accepted. |
Fixed in mainline gcc. https://golang.org/cl/26440044 http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01689.html Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What steps will reproduce the problem? : oos:aram; cd /tmp : oos:tmp; mkdir -p foo/bar/baz : oos:tmp; cd foo /tmp/foo : oos:foo; cat <<EOF >baz.go > package main > > func main() { > } > EOF : oos:foo; gccgo -o baz baz.go -lnsl -lsocket -static-libgo -static-libgcc : oos:foo; ./baz : oos:foo; PATH=/tmp/foo:$PATH : oos:foo; cd bar /tmp/foo/bar : oos:bar; baz mmap errno 19 fatal error: mmap : oos:bar; cd baz /tmp/foo/bar/baz : oos:baz; baz : oos:baz; : oos:baz; : oos:baz; cd .. : oos:bar; baz mmap errno 19 fatal error: mmap : oos:foo; What is the expected output? baz should not crash. What do you see instead? baz crashes. Which compiler are you using (5g, 6g, 8g, gccgo)? gccgo Which operating system are you using? Solaris Which version are you using? : oos:foo; gccgo -v Using built-in specs. COLLECT_GCC=gccgo COLLECT_LTO_WRAPPER=/opt/gcc482/bin/../libexec/gcc/x86_64-sun-solaris2.11/4.8.2/lto-wrapper Target: x86_64-sun-solaris2.11 Configured with: ../src/configure --prefix=/home/aram/gcc482 --build=x86_64-sun-solaris2.11 --host=x86_64-sun-solaris2.11 --disable-multilib --disable-shared --enable-threads=posix --enable-languages=c,c++,go --disable-libssp --disable-nls --with-gnu-as --with-gnu-ld --enable-ld --disable-gold Thread model: posix gcc version 4.8.2 (GCC) : oos:foo; uname -a SunOS oos 5.11 omnios-b281e50 i86pc i386 i86pc : oos:foo; cat /etc/release OmniOS v11 r151006 Copyright 2012-2013 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. : oos:foo; Please provide any additional information below. From truss: [ ... snip ...] open("baz", O_RDONLY) = 3 fcntl(3, F_SETFD, 0x00000001) = 0 mmap(0x00000000, 4096, PROT_READ, MAP_PRIVATE, 3, 0) Err#19 ENODEV [ ... snip ...] Stack trace at the mmap with wrong fd: : oos:bar; dtrace -c baz -n 'pid$target::mmap:entry /arg4 == 3/ { ustack(); }' dtrace: description 'pid$target::mmap:entry ' matched 2 probes mmap errno 19 fatal error: mmap dtrace: pid 14047 exited with status 2 CPU ID FUNCTION:NAME 1 78238 mmap:entry libc.so.1`mmap baz`backtrace_get_view+0x64 baz`elf_add+0x5f baz`backtrace_initialize+0x40 baz`fileline_initialize+0x13d baz`backtrace_pcinfo+0x2b baz`unwind+0x50 baz`_Unwind_Backtrace+0x49 baz`backtrace_full+0x35 baz`runtime_callers+0x39 baz`mcommoninit+0x37 baz`runtime_schedinit+0x8f baz`main+0x27 baz`_start+0x6c : oos:bar; Stack trace at the faulty open: : oos:bar; dtrace -c baz -n 'syscall::open:entry /copyinstr(arg0) == "baz"/ { ustack(); }' dtrace: description 'syscall::open:entry ' matched 1 probe mmap errno 19 fatal error: mmap dtrace: pid 14052 exited with status 2 CPU ID FUNCTION:NAME 0 10248 open:entry libc.so.1`_syscall6+0x1b libc.so.1`open+0x5d baz`backtrace_open+0x35 baz`fileline_initialize+0x125 baz`backtrace_pcinfo+0x2b baz`unwind+0x50 baz`_Unwind_Backtrace+0x49 baz`backtrace_full+0x35 baz`runtime_callers+0x39 baz`mcommoninit+0x37 baz`runtime_schedinit+0x8f baz`main+0x27 baz`_start+0x6c : oos:bar;The text was updated successfully, but these errors were encountered: