go binaries segfault since ba60be87355

go binaries segfault since ba60be87355

[Cristian Rodríguez]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

Hi:

I have installed ba60be87355 build on my test machine, and go binaries have
started to segfault with the following backtrace..

let's say

./caddy version

[#0] 0x155555527388 → _dl_lookup_direct(map=0x0, undef_name=0x15555554980e
"pthread_mutex_lock", new_hash=0x4f152227, version=0x1555555497ca
"GLIBC_2.2.5", version_hash=0x9691a75)
[#1] 0x155555537d03 → __rtld_mutex_init()
[#2] 0x15555553d0e5 → dl_main(phdr=<optimized out>, phnum=<optimized out>,
user_entry=<optimized out>, auxv=<optimized out>)
[#3] 0x155555539753 → _dl_sysdep_start(start_argptr=0x7fffffffd4b0,
dl_main=0x15555553b38e <dl_main>)
[#4] 0x15555553b196 → _dl_start_final(arg=0x7fffffffd4b0)
[#5] 0x15555553b196 → _dl_start(arg=0x7fffffffd4b0)
[#6] 0x155555539e08 → _start()

Anyone seeing this ? Im not blaming this specific commit, It is probably
one of the elf: changes before it.

Re: go binaries segfault since ba60be87355

[Florian Weimer]

* Cristian Rodríguez:

> I have installed ba60be87355 build on my test machine, and go binaries
> have started to segfault with the following backtrace..
>
> let's say
>
> ./caddy version 
>
> [#0] 0x155555527388 → _dl_lookup_direct(map=0x0, undef_name=0x15555554980e
> "pthread_mutex_lock", new_hash=0x4f152227, version=0x1555555497ca "GLIBC_2.2.5",
> version_hash=0x9691a75)
> [#1] 0x155555537d03 → __rtld_mutex_init()
> [#2] 0x15555553d0e5 → dl_main(phdr=<optimized out>, phnum=<optimized out>,
> user_entry=<optimized out>, auxv=<optimized out>)
> [#3] 0x155555539753 → _dl_sysdep_start(start_argptr=0x7fffffffd4b0, dl_main=0x15555553b38e
> <dl_main>)
> [#4] 0x15555553b196 → _dl_start_final(arg=0x7fffffffd4b0)
> [#5] 0x15555553b196 → _dl_start(arg=0x7fffffffd4b0)
> [#6] 0x155555539e08 → _start()

It's not Go-specific.  It happens if a program links against ld.so, but
not libc.so.  I thought we had a test for that, but apparently not.
It's not really something useful to do: ld.so does not provide any
public interfaces to load further objects, so why not link statically
instead?

I'll figure out a way to fix it and add a test.

Thanks,
Florian