Signal 6

[Doug Hardie]

-- Doug

> On 29 June 2018, at 08:56, Michael Sierchio <kudzu at tenebras.com> wrote:
> 
> Are there process limits?

Yes - defaults as best as I can tell.

brain# limits
Resource limits (current):
  cputime              infinity secs
  filesize             infinity kB
  datasize             33554432 kB
  stacksize              524288 kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked         infinity kB
  maxprocesses            12128
  openfiles              232812
  sbsize               infinity bytes
  vmemoryuse           infinity kB
  pseudo-terminals     infinity
  swapuse              infinity kB
  kqueues              infinity
  umtxp                infinity

brain# limits -p 47719    This is the current process in question - owned by root
Resource limits (current):
  pseudo-terminals        47719

brain# limits -U root
Resource limits for class root:
  cputime              infinity secs
  filesize             infinity kB
  datasize             infinity kB
  stacksize            infinity kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked         infinity kB
  maxprocesses         infinity
  openfiles            infinity
  sbsize               infinity bytes
  vmemoryuse           infinity kB
  pseudo-terminals     infinity
  swapuse              infinity kB
  kqueues              infinity
  umtxp                infinity


I am guessing that stacksize limits the heap?  But I can't tell which value is used by that process.

> malloc() will call abort() if internal structures are munged (e.g., by heap overflow).

I am suspecting this is the cause, but how do you tell what the heap usage is?

> 
> calling free() on a corrupted pointer does that reliably

This process runs on a number of different machines.  Only the one has the issue so I suspect that it is data dependent.  This one handles the most data.

> 
> is the root partition big enough for the dump?

Yes - single partition system.  191 Gb available in the / partition.

> 
> = M
> 
> On Fri, Jun 29, 2018 at 8:40 AM, Doug Hardie <bc979 at lafn.org> 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.
> 
> /etc/sysctl.conf contains:
> kern.sugid_coredump=1
> kern.corefile=/crash/%N.core
> 
> /crash is a directory in the root file system.
> 
> Other than swap issues, when would the kernel kill a process without a core dump?
> 
> -- Doug
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 
> 
> 
> -- 
> "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred."
> 
> - The Mahābhārata