go binaries segfault since ba60be87355

Florian Weimer fweimer@redhat.com
Thu Nov 7 21:37:21 GMT 2024


* 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



More information about the Libc-alpha mailing list