-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gccgo: runtime segfaults in package initialization code (only on i386 musl) #63935
Comments
The fault address is 0, but the faulting instruction is which is writing to |
|
Thanks
Yeah, the SP is not aligned at 16-byte, so is Does i386 musl not align the SP at 16-byte when starting a thread? Does this cause any problem for other code? If not, maybe you could configure gcc to not emit aligned XMM instructions? |
musl itself does seem to align the stack pointer on a 16-byte boundary in its startup code. However, you are probably referring to the code implementing So it seems that libucontext's |
One thing to also take into account is that musl does not support |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
I can reproduce it with GCC 13.2 which is the latest GCC stable release.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I maintain the Go package for Alpine Linux, for Alpine we presently use gcc-go for bootstrapping Go. As you may know, Alpine Linux uses musl libc. We upstreamed all of our downstream patches for gccgo musl support recently (#51280) and since then haven't had any issues with gcc-go. However, since musl 1.3.4 and gcc 13.X the gcc-go runtime segfaults on any Go program only on i386, on all other arches (x86_64, s390x, riscv64, aarch64, armhf, armv7) it works as intended:
The segfault seems to occur in a compiler-generated package initialization function for the unicode package:
I am not exactly sure yet when this regression was introduced. Our gccgo is largely unpatched, but unfortunately, since musl 1.2.4 removed the LFS64 large file interfaces (e.g. stat64, lseek64, open64, …) we employ a minor patch for libgo which we haven't upstreamed yet.1 However, I would be surprised if the segfault is related to this patch since the gccgo runtime works on all other architectures. On all architectures other than i386 we are also able to bootstrap Go using gccgo.
Any idea what might be causing this or any guidance on how to debug this further? (CC: @ianlancetaylor)
One can easily reproduce this on an
x86_64
machine using Docker:Please let me know if I can provide any additional information.
What did you expect to see?
I would have expected
./hello
to output "hello".What did you see instead?
The runtime fault.
Footnotes
Would also welcome suggestion on how to revise the patch in a way that it can be upstreamed. I suppose the issue is that presence of the large file interface is assumed on Linux (e.g. in
libcall_posix_largefile.go
). So I guess aconfigure
check to determine if the large file interface is supported is needed? If it isn't, a different version of variouslibcall_*'go
files would have to be used? ↩The text was updated successfully, but these errors were encountered: