Date: Mon, 29 Feb 2016 15:14:48 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Message-ID: <bug-204426-16-NiJHHPDqfa@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204426-16@https.bugs.freebsd.org/bugzilla/> References: <bug-204426-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #56 from Konstantin Belousov <kib@FreeBSD.org> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204426-16-NiJHHPDqfa>