One, you should remove sqlite-users at sqlite.org from your To list. I keep bouncing email when I reply to you. Not a big deal, just an FYI.
Two: On Sun, May 3, 2015 at 2:13 PM, James K. Lowden <jklowden at schemamania.org> wrote: > 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. ;-) > Okay, I think I see what you're saying, though there seem to be a number of anecdotes online about people who do get a sigsegv from some simple memory allocation strategies (designed to allocate all available memory). I would not discount the possibility of a sigsegv, but agree that it is probably not supposed to happen given the way optimistic memory allocation is claimed to work. > 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. > The code I was referring to in earlier posts performed a realloc. I wonder if perhaps there is a corner case in there. Growing a block potentially means moving a block, so if the library was copying from a previously allocated block to a new block, maybe that could result in a segfault? Or maybe another explanation could be that some other library other piece of code replaced the default malloc-family functions. -- Scott Robison
