when does the system send SIGKLILL
in [Unix Programming]
|
Prev: Suggestions needed
Next: A tool that suggests optimized logic for a piece of code/module/function
From: cerr on 12 Jan 2010 11:42 On Jan 11, 5:16 pm, sc...(a)slp53.sl.home (Scott Lurndal) wrote: > cerr <ron.egg...(a)gmail.com> writes: > >On Jan 11, 3:09=A0pm, Ben Finney <ben+u...(a)benfinney.id.au> wrote: > >The memory seems to be fine with "free" but I just caught a seg fault > >now: > >Program received signal SIGSEGV, Segmentation fault. > >0x0804cb4c in ?? () > >Then I tried to get a backtrace with bt but i only got: > >(gdb) bt > >#0 0x0804cb4c in ?? () > >how come? I am in the source directory and i disd compile the binary > >with -ggdb3 ... any clues? > > If your SEGV resulted in corrupting the stack, GDB will not be able to > produce a stack traceback. > > scott Mh, why would a segfault happen on the stack unless I declare a pointer and explicitly free() it before i try to access it? Variables on the stack get discarded at the end of the function and then they're out of scope anyways, eh? Not sure if i'm missing something here... Ron
From: cerr on 12 Jan 2010 12:43 On Jan 11, 4:00 pm, la...(a)ludens.elte.hu (Ersek, Laszlo) wrote: > In article <b9bed0c3-6994-44d9-aef1-029488ad8...(a)q4g2000yqm.googlegroups.com>, cerr <ron.egg...(a)gmail.com> writes: > > > I'm running Linux and i've been looking at my syslog file (all > > messages going into /var/log/messages) and i dont' see any messages > > that aren't coming from my own application....so a memory leak would > > be a reason you're saying, huh? > > Hmm....I can't see this being a problem, i think i free() everything > > that's been allocated with malloc/realloc.... > > Your process could still get killed by the OOM killer before you reach > free(). Try to turn off overcommit (and then reboot, perhaps): > > http://groups.google.com/group/comp.lang.c/msg/b6b1aff01a34738d?dmode... \ Ok, let's try this, I'set overcommit to 1 now: http://www.linuxinsight.com/proc_sys_vm_overcommit_memory.html > > If you start seeing SIGSEGVs instead of SIGKILLs, or the application > starts complaining about malloc() returning a null pointer, then the > problem is memory exhaustion. I check for a NULL pointer after every malloc and realloc and print a syslog message but I haven't seen any of these messages so far... :o > Since you may be editing /etc/sysctl.conf anyway, add this too: I can't find this file on my system > > vm.mmap_min_addr = 4096 > > http://wiki.debian.org/mmap_min_addr Thanks for these hints! -- Ron
From: Andrew Poelstra on 12 Jan 2010 12:45 On 2010-01-12, cerr <ron.eggler(a)gmail.com> wrote: > On Jan 11, 5:16�pm, sc...(a)slp53.sl.home (Scott Lurndal) wrote: >> cerr <ron.egg...(a)gmail.com> writes: >> >On Jan 11, 3:09=A0pm, Ben Finney <ben+u...(a)benfinney.id.au> wrote: >> >The memory seems to be fine with "free" but I just caught a seg fault >> >now: >> >Program received signal SIGSEGV, Segmentation fault. >> >0x0804cb4c in ?? () >> >Then I tried to get a backtrace with bt but i only got: >> >(gdb) bt >> >#0 �0x0804cb4c in ?? () >> >how come? I am in the source directory and i disd compile the binary >> >with -ggdb3 ... any clues? >> >> If your SEGV resulted in corrupting the stack, GDB will not be able to >> produce a stack traceback. >> >> scott > > Mh, why would a segfault happen on the stack unless I declare a > pointer and explicitly free() it before i try to access it? Variables > on the stack get discarded at the end of the function and then they're > out of scope anyways, eh? > Not sure if i'm missing something here... > If you try to write to memory you don't own, and that memory happens to be in the stack (or it is the stack pointer). If you write past the end of a local array this could happen, I expect. I'm just guessing here.
From: John Gordon on 12 Jan 2010 13:09 In <slrnhkpd4v.nvv.apoelstra(a)localhost.localdomain> Andrew Poelstra <apoelstra(a)localhost.localdomain> writes: > If you try to write to memory you don't own, and that memory happens > to be in the stack But if the memory contains stack information, then by definition you *do* own it, right? Because it was allocated by your process. If you are sufficiently unlucky, you could be corrupting memory in such a way that your stack gets hosed but you don't see the SEGV until later. -- John Gordon A is for Amy, who fell down the stairs gordon(a)panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies"
From: cerr on 12 Jan 2010 13:22
On Jan 12, 9:43 am, cerr <ron.egg...(a)gmail.com> wrote: > On Jan 11, 4:00 pm, la...(a)ludens.elte.hu (Ersek, Laszlo) wrote:> In article <b9bed0c3-6994-44d9-aef1-029488ad8...(a)q4g2000yqm.googlegroups.com>, cerr <ron.egg...(a)gmail.com> writes: > [snip] > > > Your process could still get killed by the OOM killer before you reach > > free(). Try to turn off overcommit (and then reboot, perhaps): > > >http://groups.google.com/group/comp.lang.c/msg/b6b1aff01a34738d?dmode... > > \ > Ok, let's try this, I'set overcommit to 1 now: > http://www.linuxinsight.com/proc_sys_vm_overcommit_memory.html Uh, it happened again, set it to 2 now... > > If you start seeing SIGSEGVs instead of SIGKILLs, or the application > > starts complaining about malloc() returning a null pointer, then the > > problem is memory exhaustion. > > I check for a NULL pointer after every malloc and realloc and print a > syslog message but I haven't seen any of these messages so far... :o > > > Since you may be editing /etc/sysctl.conf anyway, add this too: > > I can't find this file on my system > > vm.mmap_min_addr = 4096 |