runtime: uninterruptible hang on os.Exit on darwin/arm64 #43294
What did you do?
unfortunately i cant find a small reproducible example yet, or a root cause.
the program calls C code. when commenting out the C calls, the issue does not appear.
What did you expect to see?
when main() exits, the program should exit immediately
What did you see instead?
the last line in main() is executed (printf) but program wont exit for several seconds.
attempting to interrupt the program AFTER main exited using lldb will make lldb hang as well until the program finally exits and lldb just prints the exit code. pkill doesnt work either.
Interrupting the program BEFORE exiting main, works just as expected.
i'm not used to debugging macos. on linux, you can attach a syscall tracer to see which syscall is blocking, but dtrace doesnt work for me (no output). Maybe someone has an idea what runs after main and how to see it in lldb
calling os.Exit anywhere, leads to the same behaviour, so this is not a defer issue. even panic() hangs
lldb is unable to read golangs debug symbols, so the best i came up with for a breakpoint was using runtime.Breakpoint, but i cant step over it to the next instruction. i'll just forever repeat the breakpoint.
The text was updated successfully, but these errors were encountered:
sorry for not being able to try earlier. i tested git from just now including this change, and it doesnt solve it.
i dont think the fix is relevant anyway, since there aren't any atexit functions registered in my case.
its open source, but i couldnt find a good small reproducable example yet.
the last command will hang for a few seconds after being successful, but only on macos big sur.
also the same code works fine on macos being executed outside of cgo, i.e. as standalone c binary.
Unfortunately i dont know how to debug this, because lldb wont tell me where it hangs :/
there are no signal handlers or atexit being registered from the c code. it's just a bunch of protocol de/serialization around a udp socket, no threads, just socket/pipe/select/read/write , nothing in this should interfere with golang other than being blocking, so the go runtime has to dedicate a thread to the goroutine calling it
Hmmm, I cannot reproduce.
It exits quite quickly.
i believe this is a bug in macos big sur.
i dont understand why this only happens when using C code inside golang, but i suspect its some sort of security thing that classifies golang programs differently. Or maybe its just because golang uses much more memory and causes a bug in some memory mapping.
Either way, this seems unlikely to be caused by golang, so i'm closing this.