On Thu, 30 Apr 2015 12:47:57 -0600 Scott Robison <scott at casaderobison.com> wrote:
> Perhaps you are correct and "sigsegv" is not the literal signal that > is triggered in this case. I don't care, really. The fact is that an > apparently valid pointer was returned from a memory allocation > function yet can result in an invalid access for whatever reason (out > of memory, in this case). The Linux OOM killer may kill the offending > process (which is what one would expect, but one would also expect > malloc to return null, so we already know not to expect the > expected). Or it may kill some other process which has done nothing > wrong! Sure, the OS is protecting the two processes address space > from one another, but it seems to me that if one process can kill > another process, there is a problem. I have no argument with you, Scott. It's neither the first nor last thing Linix implemented in the name of efficiency that undid what previously were guarantees. My only angels-on-the-head-of-a-pin argument is that the OOM-killer doesn't invalidate malloc-returned pointers in particular. It sweeps with a much broader brush, you might say. ;-) SIGSEGV *is* significant to the OP because it doesn't signify heap exhaustion. If that signal was triggered in the heap, it indicates heap corruption. If it was triggered in the stack, it suggests the stack might been exhausted, perhaps before a pure OOM condition was reached. --jkl
