From: AITGW::"MACRO32@WKUVX1.BITNET" 3-MAR-1992 21:39:01.20 To: "macro32@WKUVX1.BITNET"@uunet.UU.NET CC: JON@uunet.UU.NET Subj: RE: VMS 5.4-2 Debugger bug ?? Received: by AITGW.DECnet (utk-mail11 v1.5) ; Tue, 3 Mar 92 21:39:16 EST Received: from ukcc.uky.edu by aitgw.ge.com (5.65/GE Gateway 1.4) id AA14088; Tue, 3 Mar 92 21:39:11 -0500 Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2) with BSMTP id 1503; Tue, 03 Mar 92 21:32:15 EST Received: from UKCC by ukcc.uky.edu (Mailer R2.08) with BSMTP id 3709; Tue, 03 Mar 92 21:31:51 EST Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 3618; Tue, 03 Mar 92 21:30:32 EST Errors-To: MacroMan@WKUVX1.BITNET X-Listname: "VMS Internals, MACRO, and BLISS Discussions" Received: from MITVMA.MIT.EDU (MAILER) by WKUVX1 (MX V3.0A) with BSMTP; Tue, 03 Mar 1992 20:31:04 CST Received: from MITVMA by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 3326; Tue, 03 Mar 92 21:22:48 EST Received: from relay1.UU.NET by mitvma.mit.edu (IBM VM SMTP V2R2) with TCP; Tue, 03 Mar 92 21:22:47 EST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28861; Tue, 3 Mar 92 21:22:29 -0500 Message-Id: <9203040222.AA28861@relay1.UU.NET> Received: from tron.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 212145.216; Tue, 3 Mar 1992 21:21:45 EST Date: Tue, 3 Mar 92 19:24:01 -0500 From: "(Jon Pinkley, Westinghouse (216)486-8300 x1335)" Reply-To: MACRO32@WKUVX1.BITNET To: "macro32@WKUVX1.BITNET"@uunet.UU.NET Cc: JON@uunet.UU.NET Subject: RE: VMS 5.4-2 Debugger bug ?? acm@nauvax.ucc.nau.edu (Anthony C McCracken) writes: > Oh, this is real cool. > > .TITLE FOO > $LCKDEF > .ENTRY FOO,^M<> > $DEQ_S FLAGS=#LCK$M_DEQALL > RET > .END FOO > > > $ MACRO/DEBUG FOO > $ LINK/DEBUG FOO > $ RUN/DEBUG FOO > DBG> SET MODE SCREEN > DBG> STEP > > And now you're hung up in outer space. Login on another terminal and > do a show user/full of the hung userid. No DBG$nnnnnn process. If you > watch it while you run the program the DBG$nnnnnn subprocess terminates > but doesn't tell the hibernating parent, so it (the parent) just sits > there. > A control-y will get it's attention and you can EXIT or STOP the > image at the dollar prompt. Pretty wierd. If you have CMKRNL priv try this: $ run foo VAX DEBUG Version V5.4-019 %DEBUG-I-INITIAL, language is MACRO, module set to .MAIN. DBG> spawn $ set proc/priv=cmkrnl $ anal/system VAX/VMS System analyzer SDA> sho sum Current process summary ----------------------- Extended Indx Process name Username State Pri PCB PHD Wkset -- PID -- ---- --------------- ----------- ------- --- -------- -------- ------ 50A00021 0001 SWAPPER HIB 16 80E84F98 80E84E00 0 50A000E3 0003 DBG$50A000A5 JON LEF 4 811A5140 81659000 1336 50A000A4 0004 JON_2 JON CUR 9 811A6120 81C53000 1466 50A000A5 0005 JON_1 JON HIB 9 811A8860 81CAD000 424 ... rest removed for brevity SDA> set proc/in=5 ! the process running FOO SDA> sho proc/lock Process index: 0005 Name: JON_1 Extended PID: 50A000A5 ---------------------------------------------------------- Lock data: Lock id: 012C022A PID: 00050005 Flags: NODLCKB Par. id: 00000000 Granted at EX Sublocks: 0 LKB: 81543AA0 Resource: 56494C41 24474244 DBG$ALIV Status: Length 18 30303041 30355F45 E_50A000 User mode 00000000 00003541 A5...... Group 002 00000000 00000000 ........ Local copy SDA> set proc/in=3 ! running DEBUGGER SDA> sho proc/lock Process index: 0003 Name: DBG$50A000A5 Extended PID: 50A000E3 ----------------------------------------------------------------- Lock data: Lock id: 0F080014 PID: 00070003 Flags: NODLCKB Par. id: 00000000 Waiting for PW Sublocks: 0 LKB: 81545550 Resource: 56494C41 24474244 DBG$ALIV Status: ASYNC Length 18 30303041 30355F45 E_50A000 User mode 00000000 00003541 A5...... Group 002 00000000 00000000 ........ Local copy SDA> Note that the FOO process (PID 50A000A5) has EX access to the user mode lock DBG$ALIVE_50A000A5, and that the DBG$50A000A5 process is waiting asynchronously for that lock. What does this suggest? Well it appears to me that the Debugger is using locks to communicate between the process running the image to be debugged (JON_1), and the process running the debugger (DBG$50A000A5). The assumption made is that the only event allowing the DBG$ process to acquire the lock, is the debugged image FOO exiting. The lock is there so that the debugging process won't hang around after the image exits, for any reason. Try this: $ define dbg$process "NONE" This will load the debugger into the same processes address space with FOO. This will solve the problem you discovered, but may cause other problems (running out of virtual address space, for instance.) IMHO this isn't a bug, it's just the way it works. (If you $DELPRC the DBG$ process the same thing would probably happen.) Jon Pinkley jon@clevax.wec.com ...uunet!tron!clevax!jon (216)486-8300 x1335