[This is a reply to https://mail-index.netbsd.org/tech-kern/2021/12/01/msg027830.html. I just joined the mailing list and can't seem to find the metadata required for a proper reply. Apologies.]
I filed https://gnats.netbsd.org/56535 for this a while ago, which has an even simpler reproducer: a direct fork() call with a child that immediately exits sometimes causes memory corruption in the parent process. We've kept looking since filing https://gnats.netbsd.org/56535 but haven't had luck on further simplification. No C reproducer yet, unfortunately. (No crashes if the Go parent process is single-threaded either.) This feels like a bug in memory management somewhere (TLB invalidation issue, bug in copy-on-write?). Fundamentally, we have the parent process getting corrupt memory after calling fork with an (effectively) no-op child. That just shouldn't happen. I think we need someone familiar with NetBSD memory management internals to help take a look. Otherwise I'm afraid we won't figure it out and will have to declare that Go doesn't work on NetBSD on AMD CPUs. gdt: that does sound like a different issue to me. It may be worth filing a bug at https://github.com/golang/go/issues with the crash details. Thanks, Michael
