Date: Mon, 01 Feb 2016 21:05:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Message-ID: <bug-204426-16-hn8mR9rxSu@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204426-16@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204426 --- Comment #26 from rblayzor@inoc.net --- (In reply to Konstantin Belousov from comment #25) I think there are two different issues maybe going on here. My original bug report should of been more specific in that application/processes that apparently ran fine prior to upgrading to 10.2-RELEASE suddenly seem to be core dumping for some reason. When these processes core dump, sometimes they are leaving good core files, sometimes they are not. (perhaps most of the time). I'm seeing a something in common with the bug John brought up. Usually when I see something like: Failed to write core file for process exim (error 14) pid 8298 (exim), uid 26: exited on signal 11 The core file is incomplete, and some of the last messages I see in the core file is "cannot access memory", or something long those lines. We'll chalk these up to maybe the bug he mentioned with the system not dumping these core files. I am telling the system to drop all cores to a specific directory that has plenty of space and is r/w. The main problem however... I have to collect more core dumps on. (if they can drop core successfully). I posted one previously that just happened the other day that Timo Sirainen said should not be possible due to the output from the backtrace. I'm still waiting for more segfaults and still post those backtraces when they are available. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204426-16-hn8mR9rxSu>