runtime: C.setgid hangs on Linux #52141
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
ianlancetaylor
added
the
NeedsInvestigation
|
This doesn't hang for me, but it does crash, which is fun: |
|
I can reproduce it on one machine (ARMv8) but not on another (x86). ARMv8 x86 No Repro (x86) |
|
What version of |
$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal |
|
Thanks. Can you confirm if this issue is new with I've not been able to reproduce it myself, but I'm wondering if you see it occurs with |
|
I was looking at https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options it says: So, if you recompile does that change anything? |
|
This reproduces for me with 1.18 and 1.17.8 in Debian Bullseye (latest), with I used these Dockerfiles and context with (It doesn't repro for me either on Fedora 35 with glibc 2.34, for what it's worth.) |
|
That makes sense since the CGo mechanism for handling The observation that compilation with |
|
Curious. As per the native test, the Dockerfile example works for me. |
|
Hmm. After upgrading my Fedora 35 host's packages, the Docker repro finishes all the steps without hanging. It looks like my upgrade was pretty significant (kernel version, Docker version, and more), and I'm not sure what might be relevant, or if it's even directly related. Downgrading Docker and my kernel (5.16.18-200.fc35 -> 5.14.18-100.fc33) didn't make it start happening again, but I'm not completely sure I did it properly. Maybe it never repros on a properly maintained Fedora 35 installation. On a fresh Ubuntu Desktop Minimal 20.04 VM, the hang repros for me with the 1.18 A new Dockerfile I wrote that uses
My guess with this info would be that the kernel version and glibc versions both have to be "old" to reproduce the issue. (Docker containers sharing the kernel with the host could be why trying to repro this way is tricky.) |
|
This C program seg faults on my machine if linked with (foo.so is the same as original.) It seems to die in the SIGSETXID handler It doesn't crash if it is not linked statically, nor if the This is a linux/amd64 machine with glibc 2.33. I'm leaning to think that this is probably a bug in the C library. |
|
Rolling forward to 1.20. Please comment if you disagree. Thanks. |
|
I'm not sure if this is a Go bug. At least for the case on my machine, it is reproducible in C. From the comments above it might be glibc version dependent. Maybe we can close it? Or we're waiting for more information? Thanks. |
|
It does look like a C bug, and I don't have more info to share here. For me we can close it. |
|
Thanks, closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
setgid:$ go run .What did you expect to see?
What did you see instead?
The
C.setgidcall hangs indefinitely.Observations
dlopenandsetgidcalls are done from the C preamblepthreadsare not used-staticis not set in the LDFLAGS directive in the C preambleThis might be related to #3871 and #9400
@rsc @ianlancetaylor
The text was updated successfully, but these errors were encountered: