runtime: musl uses signal 34 for setgid #39343
Closed
Labels
Milestone
Comments
|
According to the stack traces, it looks like the test calls the C function Separately, it looks like You can put this in a separate program by creating two files in an empty directory: x.go package cgotest
/*
#include <sys/types.h>
#include <unistd.h>
*/
import "C"
import (
"os"
"os/signal"
"syscall"
"testing"
"time"
)
func runTestSetgid() bool {
c := make(chan bool)
go func() {
C.setgid(0)
c <- true
}()
select {
case <-c:
return true
case <-time.After(5 * time.Second):
return false
}
}
func testSetgid(t *testing.T) {
if !runTestSetgid() {
t.Error("setgid hung")
}
// Now try it again after using signal.Notify.
signal.Notify(make(chan os.Signal, 1), syscall.SIGINT)
if !runTestSetgid() {
t.Error("setgid hung after signal.Notify")
}
}x_test.go: package cgotest
import "testing"
func TestSetgid(t *testing.T) {
testSetgid(t)
}What happens when you run |
Doesn't return, outputs nothing at all. Output with Not sure if helpful but here is a |
|
Thanks for the strace output. What would be really helpful is to run Right now the strace output is mixing in all the |
|
While doing that I noticed that this is definitely flaky sometimes the program terminates and sometimes (most of the times) it doesn't here is the |
|
Thanks. Looks like the C library is using signal 34 to implement I see it here in the musl sources: https://git.musl-libc.org/cgit/musl/tree/src/internal/pthread_impl.h#n117 The fix will be to change runtime/sigtab_linux_generic.go and runtime/sigtab_linux_mipsx.go to handle signal 34 the way we handle signals 32 and 33. That will have a chance of breaking some existing programs, so marking this for 1.16. |
ianlancetaylor
changed the title
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this issue
Jun 3, 2020
|
Hello, |
|
@GeorgeTsilias Sure, go for it. Note that at this stage in the release process any change will not appear until the 1.16 release. Thanks. |
|
Change https://golang.org/cl/236518 mentions this issue: |
|
This was reported earlier in musl list, and their comment is at https://www.openwall.com/lists/musl/2018/10/09/3. The suggestion there was to use |
|
With the suggested patch, I don't see the hangs anymore. And most of the time things work. But on my application I also see sometimes gopanic with backtrace: |
|
I also tested CL 236518 by backporting it to our Alpine go 1.14.3 package. When doing so the |
|
@nmeum Thanks for the comments. It's best if we can keep issues focused on specific topics, so that we know when they are fixed. For problems with musl that are not related to the use of signal 34 for |
|
With CL 236518 applied there still seem to be occasional crashes in the |
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?
Started the go test suite using:
What did you expect to see?
A successful test run.
What did you see instead?
A failed test run:
Not sure if this is just a timeout problem on my hardware (i.e. if the timeout needs to be increased) or if this is some kind of deadlock. Any ideas how I could debug this further? I am unfourtunatly not farmilar with go internals but currently trying to make the entire go testsuite pass with our Alpine Linux package and this is the only remaining test which keeps failing.
The text was updated successfully, but these errors were encountered: