Process killed by signal 9 and dumps core ???
jean-noel colin
On a Solaris 2.7 system, I have a processed that aborted and dumped a
core. When looking at the core file, I find that the process was
killed by a signal 9.
How is this possible, since AFAIK, signal 9 causes the program to
exit without a core and it is not possible to trap or block SIGKILL?
Thanks for your help
Jean-Noel Colin
< output of gdb session >
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.7"...
warning: core file may not match specified executable file.
Core was generated by `/export/home/tv256/OSV/OrderServer'.
Program terminated with signal 9, Killed.
Error while mapping shared library sections:
<>
Stuart Lamble
jean-noel colin wrote:
>Hi
>
>On a Solaris 2.7 system, I have a processed that aborted and dumped a
>core. When looking at the core file, I find that the process was
>killed by a signal 9.
>How is this possible, since AFAIK, signal 9 causes the program to
>exit without a core and it is not possible to trap or block SIGKILL?
The system probably ran out of memory; the process was probably killed
by the OS (randomly) to try to free some up.
This is about the only circumstance I've run across that causes a process
to core dump on SIGKILL.
--
I'm waiting for tech support to call me back. I'm also waiting for the
second coming of Jesus. Wanna take bets on which happens first?
Casper H.S. Dik
>On a Solaris 2.7 system, I have a processed that aborted and dumped a
>core. When looking at the core file, I find that the process was
>killed by a signal 9.
>How is this possible, since AFAIK, signal 9 causes the program to
>exit without a core and it is not possible to trap or block SIGKILL?
"Don't trust gdb".
Casper
James H. Caldwell
"Stuart Lamble" <s...@debtemp.lib.monash.edu.au> wrote in message
news:slrnamnvd...@debtemp.lib.monash.edu.au...
> The system probably ran out of memory; the process was probably killed
> by the OS (randomly) to try to free some up.
>
> This is about the only circumstance I've run across that causes a process
> to core dump on SIGKILL.
I've never seen the OS randomly kill processes to free memory and I've
had enough instances when I've seen memory pig applications kill the
performance of a server without enough RAM but loads of swap. It
sounds very dangerous for the OS to "randomly" kill processes for
any reason and would consider that an OS bug. Besides, it does not
sound like the application is being killed randomly.
James H. Caldwell
Goran Larsson
James H. Caldwell <james_h_...@yahoo.com> wrote:
> I've never seen the OS randomly kill processes to free memory and I've
IRIX from sgi does this. It is related to how virtual memory is
handled, e.g. should virtual memory be reserved when a process requests
it, or when it starts using it? If the memory is reserved immediately
then a large process may be unable to fork. If memory is not reserved
then the memory may be unavailable when the process tries to use it.
> It
> sounds very dangerous for the OS to "randomly" kill processes for
> any reason and would consider that an OS bug.
When IRIX runs out of memory and starts killing processes, then the
game is over. It gladly kills system processes and most likely cripples
the system so it has to be rebooted. I agree that this must be
considered a design bug.
--
Göran Larsson http://www.mitt-eget.com
Benjamin Kaufman
dump some years ago that got killed because it ran out of disk space or
something.
Ben
tejas bhise
Check error number to see if it points to something.
Tejas.
----------------------------------------
Just my opinion.
Dan Foster
>In article <hibb9.51$wl6....@news.uswest.net>,
>James H. Caldwell <james_h_...@yahoo.com> wrote:
>
>> I've never seen the OS randomly kill processes to free memory and I've
>
>IRIX from sgi does this. It is related to how virtual memory is
...and so does AIX, incidentally. For AIX, it's a last ditch attempt to
recover some system usability (for the admin to hop on and clean up stuff,
and avoid a fsck+reboot) when VMM (physical+swap) is exhausted or nearly so.
I've run into this a few times when things ran away really badly.
Not related to Solaris VM behavior - just adding some more random tidbits
:-)
-Dan
Chris Cox
The process should get a SIGALRM prior to the final kill in AIX.
Just one more tidbit... of course, relevancy in cus is up to the reader.