Date: Fri, 17 Mar 2017 06:30:49 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: "K. Macy" <kmacy@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD Message-ID: <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> In-Reply-To: <CAHM0Q_Mg662u9D0KJ9knEWWqi9Ydy38qKDnjLt6XaS0ks%2B9-iw@mail.gmail.com> References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> <e160381c-9935-6edf-04a9-1ff78e95d818@multiplay.co.uk> <CAHM0Q_Mg662u9D0KJ9knEWWqi9Ydy38qKDnjLt6XaS0ks%2B9-iw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok I think I've identified the cause. If an alternative signal stack is applied to a non-main thread and that thread calls execve then the signal stack is not cleared. This results in all sorts of badness. Full details, including a small C reproduction case can be found here: https://github.com/golang/go/issues/15658#issuecomment-287276856 So looks like its kernel bug. If anyone has an ideas about that before I look tomorrow that would be appreciated. Regards Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18b40a69-4460-faf2-c0ce-7491eca92782>