Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!RICHTER.MIT.EDU!krowitz
From: krowitz@RICHTER.MIT.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: Re:  Failure of tb after aqdev
Message-ID: <8908111401.AA01735@richter.mit.edu>
Date: 11 Aug 89 14:01:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35

Hmmm ... my understanding of /com/aqdev under SR9.7 is that
the program acquires the device (ie. reads the ddf file,
loads and initializes the device libraries) and then uses
pgm$invoke to start a shell which then executes your commands.
Under SR9.7 the shell seems to be invoked in-process (ie. no
new processes show up on the system when /com/aqdev is run).
If I quit out of a program which is using the previously
acquired device I can get a traceback just fine.

SR10 is a different matter ... when you use /com/aqdev to
aquire a device under SR10, you start a new process which
runs the aqdev program. When you then run your application,
yet another process gets started to handle that. When the
application dies (or you quit out of it), the process goes
away just like real Unix processes do ... but, the system
does keep a process dump file which may contain enough info
for you to get a traceback. You will need to use the "tb"
command with one of the following options (I don't know
which will work in your case): "-last" will traceback the
last process in the dump file (which could be another
process which died just after yours), "-command" will look
for the last dump which came from a process running a
particular command line, "-proc" will look for a dump 
from a particular Unix PID, an Aegis UID, or a process name.
One of these options should be able to find the dump
of your application and give you the traceback.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)