[comp.os.vms] Debugger with ANALYZE/PROCESS and detached processes

RSD1901@TAMSIGMA.BITNET (Shane Davis) (01/09/88)

I'm working on a program in VAX C which will be run as a detached process.
Right now it's running as a subprocess, but regardless it is started with
the /DUMP qualifier, which causes a process dump to be created if an exception
occurs which causes abnormal image exit. I can use ANALYZE/PROCESS_DUMP to
find out what exception occurred, but no symbols or source is available when
the debugger is invoked. I cannot LINK the object module with /DEBUG because
then the image cannot be run detached.

Is there any way to allow access to the symbols from the debugger in this
case? I was thinking about LINKing it with /SYMBOL_TABLE, but I cannot find
a command in DEBUG which allows one to specify a symbol table to be used
with the image. I cannot run the image interactively because it requires
an AST via mailbox and then it must perform $GETJPI's on the sender of the AST,
and I am not allowed multiple interactive logins and do not have WORLD
privilege to do GETJPI on any other process.

Any ideas on alternative methods of debugging will also be appreciated.

--Shane Davis
  Texas A&M Univ. XPrint programmer

BITnet:  XPMAINT@TAMVENUS               TEXnet:  THOR::XPMAINT
         RSD1901@TAMSIGMA                        ZAC::RSD1901
         X222SD@TAMVM1

rrk@byuvax.bitnet (01/11/88)

Both are possible.  You can invoke the dump analyzer specifying a /debug
image for symbols even if the crash wasn't.  You can also redefine dbg$input
and dbg$output for your detached process (usually in a group table) to debug
it directly.

nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) (01/11/88)

Shane Davis <RSD1901%TAMSIGMA.BITNET@CUNYVM.CUNY.EDU> writes:
     
> Is there any way to allow access to the symbols from the debugger in this
> case? (ANALYZE/PROCESS_DUMP)

Link your program twice, once just like now with /NODEBUG and a second
time with /DEBUG and a different /EXECUTABLE name.  Then, when you do
the ANALYZE/PROCESS_DUMP add /IMAGE=executable-with-symbols and the
symbols will be taken from the second image you linked.

= Frank J. Nagy   "VAX Guru & Wizard"
= Fermilab Research Division EED/Controls
= HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY)
= BitNet: NAGY@FNAL
= USnail: Fermilab POB 500 MS/220 Batavia, IL 60510

hydrovax@nmtsun.nmt.edu (M. Warner Losh) (01/12/88)

In article <8801091650.AA08255@ucbvax.Berkeley.EDU>, RSD1901@TAMSIGMA.BITNET (Shane Davis) writes:
> I'm working on a program in VAX C which will be run as a detached process.
> Right now it's running as a subprocess, but regardless it is started with
> the /DUMP qualifier, which causes a process dump to be created if an exception
> occurs which causes abnormal image exit. I can use ANALYZE/PROCESS_DUMP to
> find out what exception occurred, but no symbols or source is available when
> the debugger is invoked. I cannot LINK the object module with /DEBUG because
> then the image cannot be run detached.
> 
But you can run detached processes that are linked with the /DEBUG option.
There are even TWO WAYS of doing so:

i)
	RUN/NODEBUG/etc
Which gives you symbols when the debugger gets invoked (I THINK).

ii)
	DEFINE DBG$INPUT "_TXan:"/GROUP
	DEFINE DBG$OUTPUT "_TXan:"/GROUP

where TXan: is the terminal you wish to use for debugging.  A few restrictions
apply here:
	1) No one else in your group can use the debugger.
	2) You MUST be in the same group as the detached process.

You can get around 2) by not allowing ANYBODY ELSE ON THE WHOLE SYSTEM to use
the debugger by replacing the /GROUP with /SYSTEM.  I don't think that you
can get around 1) except by doing something like

	RUN/INPUT=SOME-FILE.COM/etc SYS$SYSTEM:LOGINOUT
and having some-file.com look like:
$
$ DEFINE DBG$INPUT terminal-name
$ DEFINE DBG$OUTPUT terminal-name
$ RUN/DEBUG program.
$
This is MUCH MUCH better than having to deal with CORE dumps.  I found all
of this info (at least the DBG$ stuff defined /group) in the SYSTEM SERVICES
manual Volume 8A.  Utility Routines.  pg. PSM-17.  These pages are from a 4.4
doc set, so if you are running a higher version (higher than 4.5 which has
the same doc set) then they may be in a different place.  I discovered
this trick while trying to write my own PSM (Print SyMbiot), so look in that
section of the manual.

-- 
bitnet:	lush@nmt.csnet			M. Warner Losh
csnet:	warner%hydrovax@nmtsun
uucp:	...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax
	...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax
Warning:  Hydrovax is both a machine, and an account, so be careful.