🚀 go-pugleaf

>>>>> "Mark" == Mark Rosenstein <mbr@bellcore.com> writes:

	Mark> I have an application that is killed (I assume by the
	Mark> OS). I wanted to try and figure out what was going on
	Mark> using the casevision debugger.  I was unable to figure
	Mark> out a way to catch the kill, and when the program
	Mark> mysteriously dies, all I get in the debugger is process
	Mark> xxxx: terminated.

	Mark> Is there a way to catch the kill signal with the
	Mark> casevision debugger?  With other signals (like INT) when
	Mark> set it in the signal panel, and then send the
	Mark> application (attached process) an INT, it happily
	Mark> catches it.  And I can look at the stack, etc, etc.

	Mark> When I set SIGKILL in the signal panel, and then send
	Mark> kill -9 xxxx, the process just terminates. [This also
	Mark> happens when the OS does it to me].

	Mark> Have I missed something?

Sounds like your application is leaking memory, and is running out of
swap space. Check your console window if this is what is happening.

If so, you should link your application with libmalloc_cv.a and turn
on malloc/free tracing in the Performance Panel. Then bring up Heap
View and see where you are leaking memory. If you need help, let me
know. 

kittu..

--
-------
Krishna Kolluri		1L-545		kittu@sgi.com
Silicon Graphics, Inc.			Off:(415)390-1859

In article <KITTU.93Jan11095743@shakti.shakti.wpd.sgi.com> kittu@shakti.wpd.sgi.com (Krishna Kolluri) writes:

   Newsgroups: comp.sys.sgi.misc
   From: kittu@shakti.wpd.sgi.com (Krishna Kolluri)
   Reply-To: kittu@sgi.com
   Organization: Silicon Graphics, Inc.
   References: <MBR.93Jan11085304@ponape.bellcore.com>

   >>>>> "Mark" == Mark Rosenstein <mbr@bellcore.com> writes:

	   Mark> I have an application that is killed (I assume by the
	   Mark> OS). I wanted to try and figure out what was going on
	   Mark> using the casevision debugger.  I was unable to figure
	   Mark> out a way to catch the kill, and when the program
	   Mark> mysteriously dies, all I get in the debugger is process
	   Mark> xxxx: terminated.
	   [stuff deleted ...]
	   Mark> Have I missed something?

   Sounds like your application is leaking memory, and is running out of
   swap space. Check your console window if this is what is happening.

   If so, you should link your application with libmalloc_cv.a and turn
   on malloc/free tracing in the Performance Panel. Then bring up Heap
   View and see where you are leaking memory. If you need help, let me
   know. 

   kittu..
Well, thank you mightily! I never thought of looking on the console. Your
diagnosis is incorrect (but I will add your advice to my bag of debugging
tricks) but now I at least know the right question to ask.
The error on the console is:

WARNING: Process [art-devo.r4000] pid 1227 killed due to bad page read (errno:134)

Is there a reasonable way using cvd to stop the process before it
terminates and figure out, how I might be managing to do this (like a
stack trace)? [My suspicion is that I am doing a Motif no-no, but I 
can't really begin to figure it out unless I have some clue as to where
I am running into this problem

Thanks.

Mark.

In <MBR.93Jan11184839@ponape.bellcore.com> mbr@bellcore.com (Mark Rosenstein) writes:
| The error on the console is:
| 
| WARNING: Process [art-devo.r4000] pid 1227 killed due to bad page read (errno:134)

This one is easy.  Has nothing to do with memory or swap space.
errno 134 is: Stale NFS file handle.  You are almost certainly running
the program over NFS, and the server has re-exported the filesystem 
differently.  Talk to the system admin of the server.
I also seem to recall that you can get ESTALE if the file was unlinked
on the server (which might happen if somebody was remaking the program,
depending on the makefile).

| Is there a reasonable way using cvd to stop the process before it
| terminates and figure out, how I might be managing to do this (like a
| stack trace)? [My suspicion is that I am doing a Motif no-no, but I 
| can't really begin to figure it out unless I have some clue as to where
| I am running into this problem

No, cvd can't trap this (although it can catch the exit or the signal).
I'd be astounded if this was caused by a programming error on your
part.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com

In article <up5dq14@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:

   From: olson@anchor.esd.sgi.com (Dave Olson)
   Date: 12 Jan 93 06:28:04 GMT


   In <MBR.93Jan11184839@ponape.bellcore.com> mbr@bellcore.com (Mark Rosenstein) writes:
   | The error on the console is:
   | 
   | WARNING: Process [art-devo.r4000] pid 1227 killed due to bad page read (errno:134)

   This one is easy.  Has nothing to do with memory or swap space.
   errno 134 is: Stale NFS file handle.  You are almost certainly running
   the program over NFS, and the server has re-exported the filesystem 
   differently.  Talk to the system admin of the server.
   I also seem to recall that you can get ESTALE if the file was unlinked
   on the server (which might happen if somebody was remaking the program,
   depending on the makefile).
Foo! You're right. I got overexcited, when I saw the console message, and
thought this was my problem, but these were just old messages. As you suspected
I was running over NFS and remaking the program, but I understood that. My
program really does just die (with no message in the console window) with
the message terminated in cvd.

   | Is there a reasonable way using cvd to stop the process before it
   | terminates and figure out, how I might be managing to do this (like a
   | stack trace)? [My suspicion is that I am doing a Motif no-no, but I 
   | can't really begin to figure it out unless I have some clue as to where
   | I am running into this problem

   No, cvd can't trap this (although it can catch the exit or the signal).

Ok. I was overloading the word trap. My real question was how to catch
this signal in cvd (so I could try and figure out why I was getting
terminated). I set the SIGKILL button in the cvd signal panel, and it
does not seem to catch the termination. I conducted the following simple
experiment to make sure I wasn't totally confused: I ran xclock. I
attached to it with cvd. I set every signal to be caught (including
SIGKILL) in the signal panel. I did kill -INT xxx and cvd caught it. I
did kill -9 xxx, and cvd didn't catch it, and said terminated, just
like my program. [Irix 4.0.5F, 07/15/92 CASEVision Environment,
Version 1.0, 07/15/92 WorkShop CASE products, Version 1.1]. So my question,
I think, still stands.

Finally, is there a man page that tells all the reasons a process can
be terminated?

   I'd be astounded if this was caused by a programming error on your
   part.
Sorry to have misled you.

Mark.
=-=-=-=-=-=
Unless you start somewhere, you'll go nowhere. 
               --Marvin Minsky.

In article <KITTU.93Jan11095743@shakti.shakti.wpd.sgi.com>, kittu@shakti.wpd.sgi.com (Krishna Kolluri) writes:
|> >>>>> "Mark" == Mark Rosenstein <mbr@bellcore.com> writes:
|> 
|> 	Mark> I have an application that is killed (I assume by the
|> 	Mark> OS). I wanted to try and figure out what was going on
|> 	Mark> using the casevision debugger.  I was unable to figure
|> 	Mark> out a way to catch the kill, and when the program
|> 	Mark> mysteriously dies, all I get in the debugger is process
|> 	Mark> xxxx: terminated.
|> 
|> 	Mark> Is there a way to catch the kill signal with the
|> 	Mark> casevision debugger?  With other signals (like INT) when
|> 	Mark> set it in the signal panel, and then send the
|> 	Mark> application (attached process) an INT, it happily
|> 	Mark> catches it.  And I can look at the stack, etc, etc.
|> 
|> 	Mark> When I set SIGKILL in the signal panel, and then send
|> 	Mark> kill -9 xxxx, the process just terminates. [This also
|> 	Mark> happens when the OS does it to me].
|> 
|> 	Mark> Have I missed something?
|> 
|> Sounds like your application is leaking memory, and is running out of
|> swap space. Check your console window if this is what is happening.
|> 
|> If so, you should link your application with libmalloc_cv.a and turn
|> on malloc/free tracing in the Performance Panel. Then bring up Heap
|> View and see where you are leaking memory. If you need help, let me
|> know. 
|> 
|> kittu..
|> 

It may seem non-sequiter (sp?) but here is a piece of information missing
from Kittu's reply.  IRIX 4.0.X does not preallocate Virtual Memory pages
for programs.  VM pages are allocated whenever a process reads or writes
to a particular page of memory for the first time.  It is possible that
the system will run out of virtual memory (real memory + swap) when a
memory reference is made.  If this occurs, the process will be killed.

The most common causes for this are programs which have memory leaks so
the size of the process keeps growing.  Some rather ill behaved programs
keep allocating memory until they run out so they can decide how much
memory they'll have to play with.  This strategy only works if the pages
are preallocated.  Your IRIX kernel can be reconfigured by changing the
value of availsmem_accounting to 1 in /usr/sysgen/master.d/kernel and
then running /etc/autoconfig and then rebooting.

If the program is ill-behaved when it comes to it's use of dynamically
allocated memory, Kittu's suggestion of doing malloc/free tracing may
help point out the hogs in you program.