Date: Tue, 6 Dec 2016 14:59:19 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD Message-ID: <20161206125919.GQ54029@kib.kiev.ua> In-Reply-To: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 06, 2016 at 12:31:47PM +0000, Steven Hartland wrote: > Hi guys I'm trying to help identify / fix an issue with golang where by > fork results in memory corruption. > > Details of the issue can be found here: > https://github.com/golang/go/issues/15658 > > In summary when a fork is done in golang is has a chance of causing > memory corruption in the parent resulting in a process crash once detected. > > Its believed that this only effects FreeBSD. > > This has similarities to other reported issues such as this one which > impacted perl during 10.x: > https://rt.perl.org/Public/Bug/Display.html?id=122199 I cannot judge about any similarilities when all the description provided is 'memory corruption'. BTW, the perl issue described, where child segfaults after the fork, is more likely to be caused by the set of problems referenced in the FreeBSD-EN-16:17.vm. > > And more recently the issue with nginx on 11.x: > https://lists.freebsd.org/pipermail/freebsd-stable/2016-September/085540.html Which does not affect anything unless aio is used on Sandy/Ivy. > > Its possible, some believe likely, that this is a kernel bug around fork > / vm that golang stresses, but I've not been able to confirm. > > I can reproduce the issue at will, takes between 5mins and 1hour using > 16 threads, and it definitely seems like an interaction between fork and > other memory operations. Which arch is the kernel and the process which demonstrates the behaviour ? I mean i386/amd64. > > I've tried reproducing the issue in C but also no joy (captured in the bug). > > For reference I'm currently testing on 11.0-RELEASE-p3 + kibs PCID fix > (#306350). Switch to HEAD kernel, for start. Show the memory map of the failed process. Are you able to take ktrace of the process while still producing the bug ? Where is the memory corruption happen ? Is it in go runtime structures, or in the application data ? Can somebody knowledgable of either the go runtime or the app, try to identify the initial corrupted userspace data ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161206125919.GQ54029>