Prev: Suggestions needed
Next: A tool that suggests optimized logic for a piece of code/module/function
From: Ben Finney on 11 Jan 2010 18:09 cerr <ron.eggler(a)gmail.com> writes: > On Jan 11, 1:25 pm, sc...(a)slp53.sl.home (Scott Lurndal) wrote: > > Linux has something called the Out Of Memory (OOM) killer, which > > will send SIGKILL to applications when the system is under memory > > pressure. > 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? That would only be happening if, as said above, the available system memory is low. Is that the case at the time when this behaviour occurs? -- \ “The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.” —Aahz | _o__) | Ben Finney
From: cerr on 11 Jan 2010 18:35 On Jan 11, 3:09 pm, Ben Finney <ben+u...(a)benfinney.id.au> wrote: > cerr <ron.egg...(a)gmail.com> writes: > > On Jan 11, 1:25 pm, sc...(a)slp53.sl.home (Scott Lurndal) wrote: > > > Linux has something called the Out Of Memory (OOM) killer, which > > > will send SIGKILL to applications when the system is under memory > > > pressure. > > 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? > > That would only be happening if, as said above, the available system > memory is low. Is that the case at the time when this behaviour occurs? 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? Thanks, Ron
From: David Schwartz on 11 Jan 2010 18:56 On Jan 11, 3:35 pm, cerr <ron.egg...(a)gmail.com> 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 Did you 'strip' your executable or ask your linker to do it? Did you pass 'gdb' the executable and make sure it's the exact same executable as the one that was running? DS
From: Ersek, Laszlo on 11 Jan 2010 19:00 In article <b9bed0c3-6994-44d9-aef1-029488ad851d(a)q4g2000yqm.googlegroups.com>, cerr <ron.eggler(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=source 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. Since you may be editing /etc/sysctl.conf anyway, add this too: vm.mmap_min_addr = 4096 http://wiki.debian.org/mmap_min_addr Cheers, lacos
From: Scott Lurndal on 11 Jan 2010 20:16
cerr <ron.eggler(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 |