From owner-freebsd-hackers@freebsd.org Mon Mar 27 11:47:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB05ED1F3E9 for ; Mon, 27 Mar 2017 11:47:13 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7033CB26 for ; Mon, 27 Mar 2017 11:47:13 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wr0-x22c.google.com with SMTP id w11so39383049wrc.3 for ; Mon, 27 Mar 2017 04:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=0LZ/82lJaXoxPRR5WEbTM7EqRVO6GZcSn2G6xY6VXJI=; b=sDQPUQViMcop3pZaNx6KisbaU8u+o9/azmz13G+QrHNFSY1Khz3WhmydJ9rckv9ljc TMa0o6YUA5Y0gC7wc6UZ+yVjW4VmVJw6g07HXw7HYfSgZP6fqLHOPeeZy8rtyhcvekAQ FV8a8MNU72d9B08LBNH7bzj1umt9JUs8z42CSDRs+gHHeEDehfte+wf31Q1xp4VwiPax 0xRdzGxEU8RKfjEWmYcCQ0Qr9tzCv9FHXFUZdadvDitw5LTsiGpboR9fZHEe7HbSBV1t oacSVIReHOj6XMzYZSH5iWSbgDsmszgjJPJwFJnmT4Bwnpbnwvznnva3zbJXvMg9cNK4 g5eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=0LZ/82lJaXoxPRR5WEbTM7EqRVO6GZcSn2G6xY6VXJI=; b=Xtk0/R86CHkyFCMFU2qQb6w2DLVARPLc5B4XZ6t6cYw/irK3PUCG8D+NcUWTocpLPM A0Ln/tlEqW1ye0kGsXir40xDAJ2H/rSeYAkBliuyTav7XsXF0VcTrlFYT/6LkuNsP/zN Ejr7tQocwZJfcgxv1wuCKEVYScLRQfJavgF6Zq+m9JjSCzEKiXrotVUuEXtkuB3hYTSa rlj1jSzXE5c3Lo8k/p/QIPvr8hU59WGfwYMay4NMFQ9aMrc1IlI07ttXPxdyDstE4Ib5 VQGwY5dG1/0J6SD1IWpvgPRgBnO3vNrjq0JwAIheRs2zCRVM1yg7XS0sXVv2jHz7d5Sr YwIQ== X-Gm-Message-State: AFeK/H2qUPpa9SrsdfiqIyi399dheGcSU8ajCBfFSwL3e/724AfsAi1i6k2BbzezSRz6+cqi X-Received: by 10.223.164.83 with SMTP id e19mr2808903wra.154.1490615231061; Mon, 27 Mar 2017 04:47:11 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id y65sm376945wrb.50.2017.03.27.04.47.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 04:47:10 -0700 (PDT) Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD To: Konstantin Belousov 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> <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> <20170317082333.GP16105@kib.kiev.ua> <180a601b-5481-bb41-f7fc-67976aabe451@multiplay.co.uk> <20170317124437.GR16105@kib.kiev.ua> Cc: "K. Macy" , "freebsd-hackers@freebsd.org" From: Steven Hartland Message-ID: <5ba92447-945e-6fea-ad4f-f58ac2a0012e@multiplay.co.uk> Date: Mon, 27 Mar 2017 12:47:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170317124437.GR16105@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 11:47:14 -0000 OK now the similar but unrelated issue with signal stacks is solved I've moved back to the initial issue. I've made some progress with a reproduction case as detailed here: https://github.com/golang/go/issues/15658#issuecomment-288747812 In short it seems that having a running child, while the parent runs GC, is some how responsible for memory corruption in the parent. The reason I believe this is if I run the same GC in the parent after the child exits instead of while its running, I've been unable to reproduce the issue. As the memory segments are COW then the issue might be in VM subsystem. In order to confirm / deny this I was wondering if there was a way to force a full copy of all segments for the child instead of using the COW optimisation. Is this something that would be relatively easy to hack into the kernel, and if so pointers would be appreciated. Regards Steve