On Tue, Dec 14, 2021 at 1:06 PM Michael Pratt <mpr...@google.com> wrote: > > [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.)
I spoke too soon here, we managed to get a reproducer in C today, which I've posted at https://github.com/golang/go/issues/34988#issuecomment-994115345. > > 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