runtime: a Windows application launched via Steam sometimes freezes #71242
Labels
BugReport
Issues describing a possible bug in the Go implementation.
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Windows
Milestone
Comments
|
This was originally reported at hajimehoshi/ebiten#3181 by @corfe83.
|
gabyhelp
added
the
BugReport
|
I could reproduce this even with a console application (without package main
import (
"log"
"runtime"
"runtime/debug"
"time"
)
func main() {
go func() {
for {
_ = make([]byte, 256*1024)
time.Sleep(time.Millisecond)
}
}()
for {
time.Sleep(time.Second)
var gcStats debug.GCStats
debug.ReadGCStats(&gcStats)
log.Printf("LastGC: %s, NumGC: %d, PauseTotal: %s", gcStats.LastGC, gcStats.NumGC, gcStats.PauseTotal)
}
}A freeze occurs between 00:19:21 and 00:19:37 |
Open
11 tasks
|
Apparently most of the threads got stuck at Thread 0x4 ( Thread 0x5 |
hajimehoshi
changed the title
gopherbot
added
the
compiler/runtime
mknyszek
added
the
NeedsInvestigation
|
CC @golang/runtime |
|
Does this issue reproduce with Go 1.22? |
Yes, I could reproduce this with Go 1.22.9. |
|
Do you have a stack trace for each thread, for example from a debugger? My guess based on the information provided would be that the threads are stuck in some GC-related thing (spinning up GC mark workers? that only happens on the first GC if Alternatively, the threads are going to sleep for STW, which is also based on a |
I'm afraid I'm not familiar with WinDbg. How can I get the stack traces as a file? I'll try tomorrow. Also I can insert printlns in the runtime by -overlay. I'll try this later too. |
|
I dumped stack traces by x64dbg: Stack traces by x64dbg |
|
I also dumped goroutine stacks by delve Goroutine DumpsGo sourcepackage main
import (
"log"
"os"
"runtime"
"runtime/debug"
"time"
)
func main() {
/*for _, env := range os.Environ() {
log.Println(env)
}*/
/*if runtime.GOOS == "windows" && os.Getenv("SteamClientLaunch") == "1" {
runtime.GOMAXPROCS(max(1, min(2, runtime.NumCPU()-1)))
}*/
log.Println(runtime.Version())
log.Printf("PID: %d", os.Getpid())
go func() {
for {
_ = make([]byte, 256*1024)
time.Sleep(time.Millisecond)
}
}()
for {
time.Sleep(time.Second)
var gcStats debug.GCStats
debug.ReadGCStats(&gcStats)
log.Printf("LastGC: %s, NumGC: %d, PauseTotal: %s", gcStats.LastGC, gcStats.NumGC, gcStats.PauseTotal)
}
} |
Adding println affects the behavior apparently, so I am not sure this was a correct observation, but I saw goroutines got stuck at the stdcall2 with _WaitForSingleObject.
STW was invoked on GOMAXPROCS in my case, but this was not related to the freeze. Freezing happens regardless of STW. |
package main
import (
"log"
"os"
"runtime"
"runtime/debug"
"time"
)
func main() {
debug.SetGCPercent(-1)
go func() {
for {
println("runtime.GC start")
runtime.GC()
println("runtime.GC end")
time.Sleep(5 * time.Millisecond)
}
}()
log.Println(runtime.Version())
log.Printf("PID: %d", os.Getpid())
for i := 0; i < 5; i++ {
go func() {
for {
_ = make([]byte, 256*1024)
time.Sleep(time.Millisecond)
}
}()
}
for {
time.Sleep(time.Second)
var gcStats debug.GCStats
debug.ReadGCStats(&gcStats)
log.Printf("LastGC: %s, NumGC: %d, PauseTotal: %s", gcStats.LastGC, gcStats.NumGC, gcStats.PauseTotal)
}
}The above program manually calls |
|
Thanks for the details. In the x64dbg stack traces, it looks like every thread is blocked, which seems suspicious. This thread seems particularly suspicious to me: @qmuntal is it normal for releasing a mutex to block? Or maybe this isn't actually blocked and we got lucky. @hajimehoshi could you collect another set of stack traces to see if they look similar? It's unfortunate that we didn't get symbol names for the Go code itself. I tried building #71242 (comment) with Go 1.23.2, but the addresses don't even come close to matching up. @hajimehoshi could you try manually symbolizing some of these? I think From the goroutine stacks, a GC is clearly running. A few goroutines are waiting to help out with GC assists (which is a bit odd). Two of them we can't see: These are perhaps stuck in GC mark termination, maybe in here? |
Go programStack traces by x64dbgI'll try addr2line soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Go version
go version go1.23.2 windows/amd64
Output of
go envin your module/workspace:What did you do?
Compile this Go program to an execute file (with
-ldflags="-H=windowsgui")EDIT: I could minized the case further. See #71242 (comment)
Replace an exe file in a Steam game with the compiled exe file, and run it via Steam client.
What did you see happen?
The application sometimes freezes for more than 10 seconds. For example, I saw this log
You can see a freeze happens between 22:23:57 and 22:24:18.
What did you expect to see?
The application doesn't freeze.
The text was updated successfully, but these errors were encountered: