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 13 Jan 2010 18:23 On Jan 13, 2:12 pm, la...(a)ludens.elte.hu (Ersek, Laszlo) wrote: > In article <73b9a15c-9734-4b27-92e0-1ff4d3626...(a)f5g2000yqh.googlegroups.com>, cerr <ron.egg...(a)gmail.com> writes: > > > After a reboot, /proc/sys/vm/overcommit_memory shows 0 again... :( > > Of course, that's the default. You should modify one of your init > scripts to set up this runtime kernel parameter before starting any > long-lived processes. On Debian, this is done by modifying > /etc/sysctl.conf. Hehe yup okay... lol....I should've thought of that myself... However, I see with strace something like as if a SIGSEGV would lead to a SIGKILL and I've seen this seg fault happening a couple of times in gdb but most of the times in only see the SIGKILL appearing. However, the code where it appears looks like this: while (_check_node != NULL) { _check_prg = _check_node->data; if (_check_prg != NULL){ if (check_point > (_check_prg->prg_bus.bus_timestamp + 120)) { and it happens in the first if: if (_check_prg != NULL) because it apparently is pointing somewhere invalid. Can I catch such an exception without running into a seg fault somehow? It's unequal NULL but points to an incorrect spot... How can I catch this situation? Thanks, Ron
From: Ersek, Laszlo on 13 Jan 2010 19:40 In article <2291250c-95f6-42a0-ae84-f34f51839d43(a)c34g2000yqn.googlegroups.com>, cerr <ron.eggler(a)gmail.com> writes: > and it happens in the first if: if (_check_prg == NULL) because it > apparently is pointing somewhere invalid. Can I catch such an > exception without running into a seg fault somehow? It's unequal NULL > but points to an incorrect spot... How can I catch this situation? http://www.lysator.liu.se/c/rat/c2.html#3-2-2-3 ----v---- Implicit in the Standard is the notion of invalid pointers. In discussing pointers, the Standard typically refers to ``a pointer to an object'' or ``a pointer to a function'' or ``a null pointer.'' A special case in address arithmetic allows for a pointer to just past the end of an array. Any other pointer is invalid. An invalid pointer might be created in several ways. An arbitrary value can be assigned (via a cast) to a pointer variable. (This could even create a valid pointer, depending on the value.) A pointer to an object becomes invalid if the memory containing the object is deallocated. Pointer arithmetic can produce pointers outside the range of an array. Regardless how an invalid pointer is created, any use of it yields undefined behavior. Even assignment, comparison with a null pointer constant, or comparison with itself, might on some systems result in an exception. ----^---- Comparing an invalid pointer with a null pointer constant is harmless on most mainstream platforms I suppose, so I can't tell why you get a SIGSEGV where you get it, but the above could be an explanation. .... Have I suggested to run your app under valgrind yet? Cheers, lacos
From: Golden California Girls on 13 Jan 2010 22:26 Ersek, Laszlo wrote: > In article <2291250c-95f6-42a0-ae84-f34f51839d43(a)c34g2000yqn.googlegroups.com>, cerr <ron.eggler(a)gmail.com> writes: > >> and it happens in the first if: if (_check_prg == NULL) because it >> apparently is pointing somewhere invalid. Can I catch such an >> exception without running into a seg fault somehow? It's unequal NULL >> but points to an incorrect spot... How can I catch this situation? > > http://www.lysator.liu.se/c/rat/c2.html#3-2-2-3 > > ----v---- > Implicit in the Standard is the notion of invalid pointers. In > discussing pointers, the Standard typically refers to ``a pointer to an > object'' or ``a pointer to a function'' or ``a null pointer.'' A > special case in address arithmetic allows for a pointer to just past the > end of an array. Any other pointer is invalid. > > An invalid pointer might be created in several ways. An arbitrary value > can be assigned (via a cast) to a pointer variable. (This could even > create a valid pointer, depending on the value.) A pointer to an object > becomes invalid if the memory containing the object is deallocated. > Pointer arithmetic can produce pointers outside the range of an array. > > Regardless how an invalid pointer is created, any use of it yields > undefined behavior. Even assignment, comparison with a null pointer > constant, or comparison with itself, might on some systems result in an > exception. > ----^---- > > Comparing an invalid pointer with a null pointer constant is harmless on > most mainstream platforms I suppose, so I can't tell why you get a > SIGSEGV where you get it, but the above could be an explanation. > > ... Have I suggested to run your app under valgrind yet? > > Cheers, > lacos Let me guess, the pointer variable hasn't been initialized when you compare with NULL. Just because it is a pointer doesn't mean it gets initialized to NULL. You have to do it explicitly, like any other variable.
From: David Schwartz on 14 Jan 2010 00:20 On Jan 12, 8:35 am, cerr <ron.egg...(a)gmail.com> wrote: > How would I pass GDB the executable? I just ran gdb out of the source > directory where the compiled binary is located as well... gdb <executable> <core_file> DS
From: cerr on 14 Jan 2010 17:09
On Jan 13, 4:40 pm, la...(a)ludens.elte.hu (Ersek, Laszlo) wrote: > In article <2291250c-95f6-42a0-ae84-f34f51839...(a)c34g2000yqn.googlegroups..com>, cerr <ron.egg...(a)gmail.com> writes: > > > and it happens in the first if: if (_check_prg == NULL) because it > > apparently is pointing somewhere invalid. Can I catch such an > > exception without running into a seg fault somehow? It's unequal NULL > > but points to an incorrect spot... How can I catch this situation? > > http://www.lysator.liu.se/c/rat/c2.html#3-2-2-3 > > ----v---- > Implicit in the Standard is the notion of invalid pointers. In > discussing pointers, the Standard typically refers to ``a pointer to an > object'' or ``a pointer to a function'' or ``a null pointer.'' A > special case in address arithmetic allows for a pointer to just past the > end of an array. Any other pointer is invalid. > > An invalid pointer might be created in several ways. An arbitrary value > can be assigned (via a cast) to a pointer variable. (This could even > create a valid pointer, depending on the value.) A pointer to an object > becomes invalid if the memory containing the object is deallocated. > Pointer arithmetic can produce pointers outside the range of an array. > > Regardless how an invalid pointer is created, any use of it yields > undefined behavior. Even assignment, comparison with a null pointer > constant, or comparison with itself, might on some systems result in an > exception. > ----^---- > > Comparing an invalid pointer with a null pointer constant is harmless on > most mainstream platforms I suppose, so I can't tell why you get a > SIGSEGV where you get it, but the above could be an explanation. > > ... Have I suggested to run your app under valgrind yet? I haven't been able to compile valgrind to run on our platform yet...: ( but I've ran it with strace and it looks like a SIGSEGV is leading to the SIGKILL (to shutdown the other threads) but i'm not sure how i can locate with strace where in the code it happened. GDB would only show the SIGKILL... :( -- roN |