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 14 Jan 2010 17:10 On Jan 13, 7:26 pm, Golden California Girls <gldncag...(a)aol.com.mil> wrote: > 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? > > > 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. Nah., I've been through that already.... they get initialized properly...
From: Scott Lurndal on 14 Jan 2010 17:18 David Schwartz <davids(a)webmaster.com> writes: >On Jan 12, 8:35=A0am, 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 however, in his case, he's running GDB on a different (embedded) system. In that case, 'gdb <executable>' then use the gdb command to connect to the remote system. scott
From: Moi on 14 Jan 2010 17:49 On Thu, 14 Jan 2010 14:10:12 -0800, cerr wrote: > On Jan 13, 7:26 pm, Golden California Girls <gldncag...(a)aol.com.mil> > wrote: >> 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 >> >> 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. > > Nah., I've been through that already.... they get initialized > properly... Well, then it is just a plain old memory overwrite (or a stale pointer), which are very well possible if you have made some errors in protecting your critical regions with semafores. BTW do you realize that identifiers starting with an underscore are "reserved for the implementation" ? -->> Don't use a leading underscore unless you know what you are doing. HTH, AvK
From: cerr on 14 Jan 2010 18:21 On Jan 14, 2:18 pm, sc...(a)slp53.sl.home (Scott Lurndal) wrote: > David Schwartz <dav...(a)webmaster.com> writes: > >On Jan 12, 8:35=A0am, 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 > > however, in his case, he's running GDB on a different (embedded) system. > > In that case, 'gdb <executable>' then use the gdb command to connect to the remote system. > > scott I just launched gdb with no parameters then used target remote to connect to the remote platform then i use symbol-file <path/to/binary/that's/executed/on/target> which works just fine. :) -- roN :)
From: cerr on 14 Jan 2010 18:26
On Jan 14, 2:49 pm, Moi <r...(a)invalid.address.org> wrote: > On Thu, 14 Jan 2010 14:10:12 -0800, cerr wrote: > > On Jan 13, 7:26 pm, Golden California Girls <gldncag...(a)aol.com.mil> > > wrote: > >> 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 > > >> 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. > > > Nah., I've been through that already.... they get initialized > > properly... > > Well, then it is just a plain old memory overwrite (or a stale pointer), which are > very well possible if you have made some errors in protecting your critical regions > with semafores. stale pointer was one of the keywords. I don't know if that lead to all of the SIGSEGV but it could have, there were free()s without following ptr=NULL; association which could cause errors. Now I'm seeing with strace following: [pid 15389] sched_setscheduler(15389, SCHED_OTHER, { 0 }) = 0 [pid 15389] --- SIGSEGV (Segmentation fault) @ 0 (0) --- which I assume tells me that one the schedule for one of the threads is leading to a seg fault which again leads to SIGKILLing the other threads ( all i see in gdb is SIGKILL) :( > BTW do you realize that identifiers starting with an underscore are > "reserved for the implementation" ? > -->> Don't use a leading underscore unless you know what you are doing. Oh, really? Hm yeah, I guess i need to do quite some search&replace then... thanks for that hint! -- roN |