From owner-freebsd-threads@freebsd.org Mon Feb 29 15:14:48 2016 Return-Path: Delivered-To: freebsd-threads@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 508D5AB81EF for ; Mon, 29 Feb 2016 15:14:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 417B51C86 for ; Mon, 29 Feb 2016 15:14:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1TFEmT7028539 for ; Mon, 29 Feb 2016 15:14:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Mon, 29 Feb 2016 15:14:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:14:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #56 from Konstantin Belousov --- (In reply to Robert Blayzor from comment #55) The uprintf_signal data was useful, thanks. It is quite clean that the issue occured in the child after the multithreaded fork. An evidence is in the 'CN' flags (copy on write and need copy) for all map entries of the process, except the stack. The number of stacks mapped also suggests that the parent only had one thread executing during the fork. This is confirmed also by the backtrace from the core, but for different reasons I trust the core less. The fault occured on the stack access, as indicated by the fault address. What is very interesting is the error code 7, which is hardware data indicating that this was user-mode write to the page mapped read-only. Which is again consistent with the state after fork. What I do not understand is why page fault handler did not performed COW and changed the page permission to writeable, which it should, due to rw permission on the map entry. Could you, please, apply the attached debugging patch on top of the used source and provide me the same data as now, i.e. procstat -v code and kernel messages from the patch and uprintf_signal. --=20 You are receiving this mail because: You are the assignee for the bug.=