Conference bulova::decw_jan-89_to_nov-90

	Annotations to the base note:

	We have a protected sharable image which establishes a
	rundown handler. One of our customers produced a crash
	by linking our sharable image into the HELLOWORLD program
	on decw$examples. This started my investigation of this
	problem.

	At first I could not reproduce the crash. However, a few 
	days later we updated our VMS version to V5.3-2 and that
	helped! I am presently working on finding somebody who
	has a workstation running VMS 5.2, to verify that the crash
	does indeed only happen with 5.3. I'll post a reply to
	that effect later.

	The problem observed is: upon entry into a user established
	rundown handler, when exiting from HELLOWORLD, the argument 
	list is supposed to be that established in the call to $RUNDOWN.
	However, AP at this point contains 0 - not very healthy in 
	kernel mode :-).

	To pin down the problem a bit further I tried the following:

	1 - Modified SYS$EXAMPLES:USSDISP.MAR to have its rundown
	handler contain the additional instruction:

	USER_RUNDOWN::

		TSTL	(AP)		;let's see if this produces an ACCVIO

	;  remaining rundown handler stays the same

	2 - Use the following file to link USSDISP into sharable
	image USS:

$!**************************************************************
$!
$!	Command file to link User System Service example.
$!
$ LINK/PROTECT/NOSYSSHR/SHARE=USS/MAP=USS/FULL SYS$INPUT/OPTIONS
!
!	Options file for the link of User System Service example.
!
	SYS$SYSTEM:SYS.STB/SELECTIVE
!
!	Create a separate cluster for the transfer vector.
!
	CLUSTER=TRANSFER_VECTOR,,,SYS$DISK:[]USSDISP.OBJ
!
	GSMATCH=LEQUAL,1,1

$!**************************************************************

	3 - Use the following file to link helloworld:

$!**************************************************************
$ link helloworld, sys$input/opt
	sys$share:decw$dwtlibshr/share
	SYS$DISK:[]USS /SHARE
$!**************************************************************

	4 - Install the USS sharable via:

$!**************************************************************
$DEF USS SYS$DISK:[]USS.EXE
$INSTALL REMOVE USS
$INSTALL ADD USS /PROTECTED /HEADER_RESIDENT /SHARED
$!**************************************************************
	
	5 - Run helloworld to completion (exit) and watch the
	machine crash. (I normally run it with delta, because
	I get tired of waiting for my workstation to re-boot -
	:-).

	The AP contains 0 upon entry into the USS established 
	rundown handler. The image activator seems to establish
	the USS rundown handler as the first in the list pointed
	to by CTL$GL_USRUNDWN. There is a second rundown handler 
	established, I suppose it belongs to the DECW$DWTLIBSHR 
	sharable image ?

	I also tried to have a program:

 
;++
; FUNCTIONAL DESCRIPTION:
; 
;	Program TC. Does absolutely nothing but exit
; 
;--
        .ENTRY  TC,^M<R2,R3,R4,R5,R6,R7,R8,R9,R10,R11>
	MOVL	#1, R0
	RET
        .END	TC

	to see if this would crash the system upon exit, if linked
	like helloworld above. It does NOT.

	This is really what makes me enter this little story in
	this notes-file. It sure looks as if calling (certain) 
	DECwindows routines is what provokes the slightly unexpected
	AP value upon rundown entry. (?)

	Note: a rundown handler which does not access (AP) does not 
	have a problem. (I looked with SDA in what I assumed to be 
	the decw$dwtlibshr rundown handler, and that does NOT access 
	(AP) - no ACCVIO).

	What do you say? Does this sound familiar? Am I doing something
	wrong or just weird ?

	Hope you can help me.


						- Mike

This sounds like a serious problem to me.  Please QAR this problem.
Your analysis so far is excellent.  All you should have to do is
put in your QAR exactly what you've written in your note.

I don't know if DECW$DWTLIBSHR establishes a rundown handler, but
I do know that the DECwindows transport interface establishes one.
It sounds like something along the line is trashing AP.

    AP is a register. It has a special meaning for the CALL instructions,
    but it's still just a register; the C compiler will often use it as a
    temporary; that's probably what's 'trashing' AP on you.
    
    Who wrote this rundown handler? DEC or a customer? More specifically,
    is it some part of VMS or custom software? If your own rundown handler
    is crashing because AP isn't a pointer to an argument list, fix your
    code. If it's VMS code, QAR or SPR it.
    	-Rick

Huh?  Rundown handlers are invoked by CALL as far as I remember, in which
case they have a perfect right  to expect a meaningful AP on entry.
What happens after that point is up to the code in the handler, but that
wasn't what .0 seemed to talk about.

	paul

RE: .0, .4

From page A-2 of the INTRO TO SYSTEM SERVICES manual:

	PLV$L_USRUNDWN--Contains a self-relative pointer to the user-supplied
	rundown routine.  This offset is optional.  This routine is intended
	to be used for image-specific cleanup and resource deallocation.  When
	the image linked against the user-written system service is run down by
	the system, this run-time routine is invoked.  Unlike exit handlers,
	it is always called when a process or image exits.  (You call this
	routine with a JSB instruction; it returns with an RSB instruction in
	kernel mode, at IPL 0.)  For information about exit handlers, see
	Sectoin 8.6.3.

This paragraph seems to be saying that kernel mode rundown handlers for user-
written system services are called using JSB/RSB linkage.  If this is the case,
AP will not have any meaningful value and in fact this would seem to be borne
out by the behavior of the code shown in .1.

--PSW

Unfortunately, much inner-mode behavior is not documented, except in
the code itself.  Here is a comment block from SYSRUNDWN.MAR:

;-------------------------------------------------------------
;
;       INVOKE THE USER RUNDOWN SERVICE(S)
;
;       The user service is invoked in KERNEL mode with a JSB and must
;       exit with a RSB.
;
;       R4 - Pointer to current PCB
;       R7 - Access mode parameter to SYSRUNDWN maximized with previous mode
;       ACMODE(AP) - Access mode parameter to SYSRUNDWN
;
;-------------------------------------------------------------

So, although the kernel mode rundown handler is called by a JSB,
I believe that AP must still be preserved, as it points to the
arguments to the rundown system service itself.  The fact that
AP contains a 0 says to me that something has trashed AP.

I am speculating that this might have something to do with the
DECwindows transport exec mode rundown handler, as exec mode
rundown handlers are a new thing with VMS V5.3.  There may still
be some bugs there.

Re .5: me and my big mouth.  Sorry about that, I couldn't think of where
to look so I didn't look.

	paul