In https://github.com/golang/go/issues/74187#issuecomment-2992284502, @n2vi reported a large number of idle go tool trace .../flightrecordNNNN processes piling up on their openbsd-ppc64 builder.
In https://groups.google.com/g/golang-dev/c/p5eBs5k-ZXU/m/-bZVcRVDAgAJ, @mengzhuo reports the same thing on their riscv64 builders.
In a one-off check, @dmitshur sees the same thing on linux-arm builders.
From a quick search, the only place I see files created with a name like flightrecord is in gopls: https://cs.opensource.google/go/x/tools/+/master:gopls/internal/debug/flight.go;l=50;drc=0d2de46602636e75ef9960a2b53202dc34827ca8. So I suspect that gopls is the source of these left over processes.
This code intentionally avoids waiting on the subprocess, instead saying it relies on the child receiving SIGPIPE receiving when the parent exits. Perhaps this isn't working in some cases? Or the child is not actually exiting when it receives SIGPIPE?
cc @golang/tools-team @golang/release
Comment From: prattmic
I haven't double-checked the actual behavior, but from https://man7.org/linux/man-pages/man7/pipe.7.html it sounds like SIGPIPE is only generated if you actually try to write to the pipe. go tool trace won't write to stdout/stderr after initialization, so perhaps this is the problem?
Comment From: gabyhelp
Related Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)