Could you try if patching in CL https://go-review.googlesource.com/c/go/+/269378 helps? Thanks.

Change https://golang.org/cl/269378 mentions this issue: runtime: use _exit on darwin

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.
also atexit functions run inside userland and don't block lldb. this is more likely a syscall hanging,
maybe something to do with memory cleanup?

Is it possible to share the source code of a reproducer?

its open source, but i couldnt find a good small reproducable example yet.

git clone https://github.com/devguardio/carrier.git
cd carrier/cli/
go build -a
./cli identity
./cli net trace

the last command will hang for a few seconds after being successful, but only on macos big sur.
and only if cgo was called. It's of course possible this is a bug in the C code, leading to memory corruption somewhere in go, although there is no osx specific code, its just posix, so same code works fine on linux.

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.

% time ./cli identity
cDEXIP6HRNN7VV4R5TGZXNZ2XRZYXECD2LQHYBBS5F5RP3N3C6ZAZSCI
./cli identity  0.02s user 0.01s system 91% cpu 0.041 total
% time ./cli net trace
conduit.go:112: bootstrap
[WRN] carrier::endpoint timeout waiting for broker response
conduit.go:184: started broker con
[WRN] carrier::endpoint timeout waiting for broker response
conduit.go:184: started broker con
[WRN] carrier::endpoint timeout waiting for broker response
conduit.go:184: started broker con
conduit.go:53: started conduit
{
  "publishers": 0,
  "bytes_sent_per_epoch": 0,
  "bytes_recv_per_epoch": 0,
  "bytes_sent_per_second": 0,
  "bytes_recv_per_second": 0
}
conduit.go:60: stopping conduit
conduit.go:77: stopped conduit
./cli net trace  0.06s user 0.03s system 11% cpu 0.746 total

It exits quite quickly.

yeah, network wasnt available, so it didnt do anything.
let me try to reduce to a test without network

i believe this is a bug in macos big sur.
simply sending packets slower makes the issue go away. It might be that something is waiting for network responses on behalf of the program, even though it has already closed the socket.

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.

Thanks for the investigation.

If you think Go uses more memory (or other resources) than it should, feel free to reopen or file a new bug. Thanks.