PROBLEM: (52718, 74111, 61261) (PATCH ID: OSF445-067)
*******

Problem 1:  Dbx stack trace is incomplete.
 In certain cases, dbx's 'where' command did not produce a complete stack
 trace.  This was seen when debugging at the assembly level and using the 
 'stepi' command to step into a routine, or when there is a fault in some
 library routines.  The following shows some instances of the problem.
 
 Stepping into a routine with stepi ('si'), 
 Getting a stack trace ('where' or 't')
 Attempt to 'return'
 
 >*[main:68, 0x1200018b0]        ldq     r27, -32568(gp)
 (dbx) ni
 >*[main:68, 0x1200018b4]        jsr     r26, (r27), 0x120005e60
 (dbx) si
 >*[_OtsMove, 0x3ff800d5e60]     amask   0x1, r19
 (dbx) t
 >  0 _OtsMove(0x3ff800d5bd0, 0x4, 0x120001850, 0x3, 0x4) [0x3ff800d5e60]
 (dbx) return
 
 no place to return to
 (dbx) up
 (dbx) t
 >  0 _OtsMove(0x3ff800d5bd0, 0x4, 0x120001850, 0x3, 0x4) [0x3ff800d5e60]
 
 
 Stepping into a routine until the stack is correct
 
 >*[main:68, 0x1200018cc]        ldq     r21, 40(r8)
 (dbx) ni
 >*[main:68, 0x1200018d0]        bsr     r26, recurse+0x8(line 29)
 (dbx) si
 >*[recurse:29, 0x120001638]     ldq     r28, -16448(sp)
 (dbx) t
 >  0 recurse(inbox = (...)) ["crashit.c":29, 0x120001638]
 (dbx) ni
 >*[recurse:29, 0x12000163c]     ldq     r28, -4096(sp)
 (dbx) ni
 >*[recurse:29, 0x120001640]     ldq     r28, -12256(sp)
 (dbx) ni
 >*[recurse:29, 0x120001644]     lda     sp, -16448(sp)
 (dbx) ni
 >*[recurse:29, 0x120001648]     stq     r26, 8144(sp)
 (dbx) t
 >  0 recurse(inbox = (...)) ["crashit.c":29, 0x120001648]
 (dbx) ni
 >*[recurse:29, 0x12000164c]     stq     r16, 16400(sp)
 (dbx) t
 >  0 recurse(inbox = (...)) ["crashit.c":29, 0x12000164c]
    1 main(argc = 3, argv = 0x11ffffce8) ["crashit.c":68, 0x1200018d0]
 
 
 Problem 2:  Dbx cannot set a variable after viewing a non-local variable:
 Dbx has several methods of looking for variables.  If the variable is not 
 found in the current routine, active procedures on the stack are searched,
 and then global variables are searched.  When dbx searched up the stack for
 the variable, it failed to reset an internal pointer and the assignment to a
 local variable failed.  
 
 main:  52  if (argc < 3) {
 (dbx) stop in justtryme
 [2] stop in justtryme
 (dbx) r 0 3
 [2] stopped at   [justtryme:21 ,0x1200015d4]    deepend = levels;
 (dbx) n
   [justtryme:23 ,0x1200015d8]   printf("Cpu %d going down, 
	stack about %d levels deep\n", cpu, deepend);
 (dbx) p iter    /* A variable local to the main routine
 3
 (dbx) assign deepend = 10
 10
 (dbx) p deepend
 3
 (dbx) q

 Problem 3:  Dbx receives signal 66 on vfork:
 
 When debugging a program that executes a vfork, dbx exhibited this:
 
 dbx version 3.11.10
 Type 'help' for help.
 
 main:  11  signal( SIGCHLD, handler );
 (dbx) r
 signal [signal 66] at >*[__vfork, 0x3ff800e7968]    beq   r19, 0x3ff800e7980
 (dbx)
 
 The correct behaviour follows:
 
 main:  11  signal( SIGCHLD, handler );
 (dbx) r
 New child attached.  Use switch to gain access to process 5774
 child: 5774
 (dbx)