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)