From owner-freebsd-questions@freebsd.org Mon Jul 9 05:37:12 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 169CD1044534 for ; Mon, 9 Jul 2018 05:37:12 +0000 (UTC) (envelope-from srs0=+2ih=jz=mail.sermon-archive.info=doug@sermon-archive.info) Received: from mail.sermon-archive.info (sermon-archive.info [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id ACAE581BBD for ; Mon, 9 Jul 2018 05:37:11 +0000 (UTC) (envelope-from srs0=+2ih=jz=mail.sermon-archive.info=doug@sermon-archive.info) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 41PDc62XgMz2fjRB; Sun, 8 Jul 2018 22:37:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Signal 6 From: Doug Hardie In-Reply-To: Date: Sun, 8 Jul 2018 22:37:09 -0700 Cc: freebsd-questions Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D66C7A3-EBE6-475C-8360-CAFEAEA4D328@mail.sermon-archive.info> To: Michael Sierchio X-Mailer: Apple Mail (2.3445.8.2) X-Virus-Scanned: clamav-milter 0.99.4 at mail X-Virus-Status: Clean X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 05:37:12 -0000 > On 29 June 2018, at 08:57, Michael Sierchio = wrote: >=20 > One way to find out is to register a handler for SIGABRT and print and = flush the context. Registering a handler is easy. The stack is shown through backtrace(). = However, if the backtrace is in the main code, it shows the complete = stack. If it is in an interrupt handler function then it only shows the = call to backtrace. Is there some way to give it access to the complete = stack? >=20 > On Fri, Jun 29, 2018 at 8:56 AM, Michael Sierchio = wrote: > Are there process limits? >=20 > malloc() will call abort() if internal structures are munged (e.g., by = heap overflow). >=20 > calling free() on a corrupted pointer does that reliably >=20 > is the root partition big enough for the dump? >=20 > =3D M >=20 > On Fri, Jun 29, 2018 at 8:40 AM, Doug Hardie wrote: > I have a daemon process that runs forever (almost). Something is = killing it with a signal 6, but no core dump is done. If I manually = kill it with kill -6, then the log message shows core dumped and a core = file is created. The process has no reference to SIG_ABRT, so I suspect = the kernel is doing the kill and is overriding the core dump. I have = previously encountered a similar issue where swap space was running out = and the kernel killed this process without a core dump. In that case = there were quite a few messages logged about swap space issues before = the process was killed. There are no swap messages logged this time. >=20 > /etc/sysctl.conf contains: > kern.sugid_coredump=3D1 > kern.corefile=3D/crash/%N.core >=20 > /crash is a directory in the root file system. >=20 > Other than swap issues, when would the kernel kill a process without a = core dump? >=20 > -- Doug >=20 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org" >=20 >=20 >=20 > --=20 > "Well," Brahma said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five = hundred." >=20 > - The Mah=C4=81bh=C4=81rata >=20 >=20 >=20 > --=20 > "Well," Brahma said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five = hundred." >=20 > - The Mah=C4=81bh=C4=81rata