Conference bulova::decw_jan-89_to_nov-90

2090.0. "DECterm sessions hang" by PITMAN::GARROD () Fri Jan 19 1990 18:48

    
    We're having a problem with a workstation where multiple DECTERM
    processes hang.
    
    I took a crash of the machine and discovered the following.
    The process is hung in supervisor AST mode in the CLI. Looking
    at the listings shows that it has just issued a $BRKTHRW_S
    to issue a ^T message. The $BRKTHRW_S is not returning ie the process
    is LEFing.
    
    Below is a little of the information from the crash dump.
    You'll notice that a couple of the channels to the controlling terminal
    TWA2: are BUSY. Unfortunately I don't know how to go into the TWDRIVER
    data structures to find out why the QIO isn't completing.
    Please could somebody tell me how to do this. Unfortunately I don't
    have TWDRIVER listings but I do have VMS listings.
    
    It's exactly as if the user had hit HOLDSCREEN or ^S but he hasn't.
    
    Process index 21 is hung and that is the one looked at below. In
    addition the process with an index of 22 is also hung.
    
    Any help would be appreciated, this is VMS V5.3 by the way,
    
    Thanks,
    
    Dave 
    

SDA> SHO SUM
Current process summary
-----------------------
 Extended Indx Process name    Username    State   Pri   PCB      PHD    Wkset
-- PID -- ---- --------------- ----------- ------- --- -------- -------- ------
 2A600041 0001 SWAPPER                      HIB     16 8016F998 8016F800      0
 2A600047 0007 ERRFMT          SYSTEM       HIB     12 80294640 805EEE00     69
 2A600048 0008 CACHE_SERVER    SYSTEM       HIB     16 8028A210 806DE800     55
 2A600049 0009 CLUSTER_SERVER  SYSTEM       HIB     13 80289E90 8054F200     61
 2A60004A 000A OPCOM           SYSTEM       HIB     11 8028A530 80609800    102
 2A60004B 000B AUDIT_SERVER    AUDIT$SERVER HIB     10 8028A7E0 80584600     70
 2A60004C 000C JOB_CONTROL     SYSTEM       HIB     12 802965C0 80569C00    240
 2A60004D 000D CONFIGURE       SYSTEM       HIB     10 8029E860 804E4A00    141
 2A60004E 000E SMISERVER       SYSTEM       HIB     11 8029EAB0 804FF400     48
 2A60004F 000F NETACP          DECNET       HIB     10 8029F070 805D4400    517
 2A600050 0010 EVL             DECNET       HIB      5 802AF8E0 80534800     34
 2A600051 0011 REMACP          SYSTEM       HIBO    12 802B3A10 00000000     28
 2A600054 0014 DECW$SERVER_0   SYSTEM       HIB      6 802B70D0 80659600   1336
 2A600055 0015 BELANGER        BELANGER     LEF      9 802BAF20 80674000    300
 2A600056 0016 DNS$ADVER       SYSTEM       HIB      9 802BB8A0 8063EC00    113
 2A600057 0017 DFS$COM_ACP     <dfs$comacp> HIB     13 802CBD70 8068EA00     88
 2A600058 0018 INSPECT$Exec    SYSTEM       HIB      9 802CD660 8059F000     48
 2A600059 0019 DTSS$SERVICE    SYSTEM       LEF     10 802D34C0 80624200    216
 2A60005B 001B DECW$WM_1       BELANGER     LEF      7 802D47D0 80519E00    650
 2A60009C 001C _TWA4:          BELANGER     LEF      9 803089E0 8077E400   1174
 2A60005D 001D ** DREAMER **   BELANGER     LEF      4 802D5620 805B9A00   1152
 2A600060 0020 DECW$TE_1       BELANGER     LEF      6 802D72D0 806F9200    651
 2A600061 0021 NOTHING BUT A   BELANGER     LEF      9 802D87D0 80749000    280
 2A600062 0022 _TWA3:          BELANGER     LEF      9 802D8DE0 8072E600    500
 2A600063 0023 DECW$AUTOFOCUS  BELANGER     LEF      8 802D9230 806A9400    137
 2A600064 0024 NMAIL           SYSTEM       HIB      9 802D9F90 80763A00     32
SDA> SET PROC/IND=21
SDA> SHO PROC
Process index: 0021   Name: NOTHING BUT A   Extended PID: 2A600061
------------------------------------------------------------------
Process status:  02040001   RES,PHDRES

PCB address              802D87D0    JIB address              80433360
PHD address              80749000    Swapfile disk address    00000000
Master internal PID      00010021    Subprocess count                0
Internal PID             00010021    Creator internal PID     00000000
Extended PID             2A600061    Creator extended PID     00000000
State                       LEF      Termination mailbox          0000
Current priority                9    AST's enabled                KESU
Base priority                   4    AST's active                 S   
UIC                [00307,000034]    AST's remaining               321
Mutex count                     0    Buffered I/O count/limit       98/100
Waiting EF cluster              0    Direct I/O count/limit        100/100
Starting wait time       1B001B1B    BUFIO byte count/limit      32528/32768
Event flag wait mask     7FFFFFFF    # open files allowed left     100
Local EF cluster 0       40000001    Timer entries allowed left     20
Local EF cluster 1       80000000    Active page table count        29
Global cluster 2 pointer 00000000    Process WS page count         166
Global cluster 3 pointer 00000000    Global WS page count          114
SDA> SHO CALL
Call Frame Information
----------------------
	Call Frame Generated by CALLS Instruction

Condition Handler	7FFEC7AC  00000000	
SP Align Bits = 00	7FFEC7B0  207C0000
   Saved  AP		7FFEC7B4  7FFEC81E	
   Saved  FP		7FFEC7B8  7FFEC7E0	
   Return PC		7FFEC7BC  80000343	EXE$WAIT_FORM+00023
	R2		7FFEC7C0  00000001	
	R3		7FFEC7C4  00000020	
	R4		7FFEC7C8  00002270	UCB$M_TEMPLATE+00270
	R5		7FFEC7CC  802D8360	
	R6		7FFEC7D0  7FFD3518	
Align Stack by 0 Bytes =>
Argument List		7FFEC7D4  00000002
			7FFEC7D8  0000001F	
			7FFEC7DC  7FFEC84E	

SDA> SHO CALL/NEXT
Call Frame Information
----------------------
	Call Frame Generated by CALLS Instruction

Condition Handler	7FFEC7E0  00000000	
SP Align Bits = 10	7FFEC7E4  AFFC0000
   Saved  AP		7FFEC7E8  7FFECA34	
   Saved  FP		7FFEC7EC  7FFEC9F8	
   Return PC		7FFEC7F0  7FF86577	
	R2		7FFEC7F4  7FFEC85E	
	R3		7FFEC7F8  7FFEC856	
	R4		7FFEC7FC  802D87D0	
	R5		7FFEC800  7FFEC95A	
	R6		7FFEC804  7FFEC8EA	
	R7		7FFEC808  7FFEC95A	
	R8		7FFEC80C  7FFEC966	
	R9		7FFEC810  7FFEC9BE	
	R10		7FFEC814  7FFEC9D6	
	R11		7FFEC818  7FFEC9F8	
Align Stack by 2 Bytes =>
Argument List		7FFEC81E  0000000B
			7FFEC822  0000001F	
			7FFEC826  7FFEC85E	
			7FFEC82A  7FFEC856	
			7FFEC82E  00000001	
			7FFEC832  7FFEC84E	
			7FFEC836  00000020	
			7FFEC83A  00000000	
			7FFEC83E  00000006	
			7FFEC842  00000000	
			7FFEC846  00000000	
			7FFEC84A  00000000	

SDA> SHO PROC/CHAN
Process index: 0021   Name: NOTHING BUT A   Extended PID: 2A600061
------------------------------------------------------------------


                            Process active channels
                            -----------------------

Channel	 Window		  Status	Device/file accessed
-------	 ------		  ------	--------------------
  0010	00000000	          	DUA0:
  0020	804B1F60	          	QUATLU$DUA0:(666,2,0) (section file)
  0030	00000000	     Busy 	TWA2:
  0040	00000000	          	DUA0:
  00A0	00000000	          	TWA2:
  00B0	00000000	     Busy 	TWA2:
SDA> SHO DEV TWA2
TWA2                                    VT300_Series      UCB address:  802D8360

Device status:   00000012 int,online
Characteristics: 0C040007 rec,ccl,trm,avl,idv,odv
                 00000200 nnm

Owner UIC [000307,000034]   Operation count        229   ORB address    802D84F0
      PID        00010021   Error count              0   DDB address    804AC2C0
Class/Type          42/70   Reference count          3   DDT address    802F7701
Def. buf. size         80   BOFF                  0001   CRB address    804265D0
DEVDEPEND        180093B0   Byte count            0100   I/O wait queue    empty
DEVDEPND2        FB901004   SVAPTE            8029E300                          
FLCK index             34   DEVSTS                0000                          
DLCK address     801A30F0                                                       

	*** I/O request queue is empty ***

    PS If nobody knows the answer to this please could someone point me at
       at the TWDRIVER listings. I can't seem to locate them on the RESD$
       roots on BULOVA. I can find TTDRVR but not TWDRIVER and I suspect
       that TWDRIVER has a different UCB layout to TTDRIVER.
    
    Many thanks,
    
    Dave

Re: .0

I've seen a problem where DECterm hangs trying to do output; I think it is
expecting to receive a NoExpose event that never arrives (or more likely has
an unexpected serial number).  To clear the condition use either Clear
Communication or Reset Terminal (I don't remember which) from the Commands menu.

				-- Bob

    Re .2
    
    Could you tell me the footprint of this condition. I have a crash dump
    to look at. I also have access to listings.
    
    I know my way around VMS and VMS crashdumps but I'm a real neophyte as
    far as DECwindows is concerned. Could AUTOFOCUS cause this? The user
    who's workstation does this uses AUTOFOCUS.
    
    What exactly is a NOEXPOSE event anyway, yes I know that this is an
    incredibly naive question and no I have never read a DECwindows manual.
    So if you think my knowledge level is too low to answer this I'll
    understand.
    
    Dave

    If anybody wants to look at the dump it is on:
    
    PITMAN::DUA0:[GARROD]ULTMAT.DMP
    
    SET PROC/INDEX=21
    
    will set you to one of the processes that is hung trying to do a ^T
    output to the terminal.
    
    Dave

>>    What exactly is a NOEXPOSE event anyway, yes I know that this is an
>>    incredibly naive question and no I have never read a DECwindows manual.

Actually this is not such a naive question.

The NoExpose event is sent by the server to a client that has made
a CopyArea or CopyPlane request when the destination rectangle is
completely occluded.

When a client issues an XCopyArea or XCopyPlane request, it often wants
to synchronize with the server and needs a way to tell when the operation
is done.  Usually, it can depend on their being exactly one GraphicsExpose
event with a zero count field.  However, if the destination is not visible,
then no GraphicsExpose events can be sent.  It is fortunate that the X
designers took into consideration and included a NoExpose event to be
sent in place of the series of GraphicsExpose events.

In other words, NoExpose events signal the completion of a CopyArea or
CopyPlane that didn't do anything.

Any more questions?

:)

-steve-

Re: .3

I don't know enough about crash dumps to tell you what to look for; there's a
bit that would be set in the DECterm widget block, but it isn't especially
easy to figure out where this block is located in memory.  If DECterm becomes
unfrozen when you Reset Terminal/Clear Communication then it probably missed
a NoExpose event.  I don't know of a way to avoid losing the event, but
once you've lost it Reset Terminal/Clear Communication will clear up the
problem.

Another way DECterm can freeze up is if it runs out of a resource like
BYTLM; I think the process hangs in an MWAIT state.  Someone else could tell
you more about that than I can.

Re: .5

I think a NoExpose event is also generated if you XCopyArea with the
graphics_expose bit set and the window is completely visible: there is no
rectangle that needs to be redrawn.  Actually, DECterm looks for either a
NoExpose or GraphicsExpose event with the right serial number.

				-- Bob

    OK it happened again. Indeed doing a CLEAR COMM unfroze the window.
    Is this considered to be a DECwindow's bug, should I QAR it?
    If I QAR it on TRIFID how do I submit the crash dump?
    
    It sounds like analyzing the dump myself is beyond my capabilities, I
    hardly even know what a widget is, let alone a widget control block!
    I initially thought it might be an I/O problem of some sort which is
    why I mentioned TWDRIVER (which I probably could have analyzed myself)
    but you DECwindows gurus have convinced me that it is a DECwindows
    bug/feature.
    
    If it is not a bug, how do I prevent it from happening?
    
    Thanks again,
    
    Dave
        

Re: .7

It's a bug either in DECterm (most likely) or in some other part of DECwindows.
I'm not sure if there's a QAR on it, so please submit a QAR.  I doubt that a
crash dump will be helpful, but if you decide to include the crash dump you 
should either put a file name for the crash dump in the QAR or else say
something like "Send me mail if you'd like to see the crash dump" (this would
allow you to store the crash dump on tape, for example).

				-- Bob

    I have been having the same problem.  Doing a CLEAR COMM does fix it, 
    but I want to try to prevent it.  Any new suggestions would be
    appreciated.
    Thanks

Re: .9

If you quit out of the session manager (or log out of all your DECterm windows)
every night instead of pausing you probably won't see this problem very often.

By the way, I've fixed this problem in the latest internal version of DECterm,
and now the only question is deciding which version of VMS it should be
released with.

				-- Bob

I was just talking with several people yesterday that were seeing this problem
daily.  Are you making `special field test' versions available?  While this
might be a hassle to track, I beleive that there is reason to get some of the
important DECterm fixes out soon, but given the status of various releases
it may not be easy to get much testing of these fixes soon.

Re: .11

Currently the answer is "no".  I've checked the fix into the DECwindows V3
code stream, but it didn't make it into T5.4.  Since we've received a CLD on
this problem we'll probably have to provide a patch for V5.3.  I'd like to
put the bug fix into V5.4 SSB, but that's up to the "powers that be".

				-- Bob

Hi,
	Could you post the latest status of the patch for vms 5.3 and if it will
make vms 5.4 please.

			Andy

Hi,
  Since Bob Messenger was good enough to give us the modified code, we have 
built a new DECW$TERMINALSHR.EXE to fix this problem.  Please ask your CSC for
patch TERMSHR$IMAGE01_530.  This is good for all flavors of 5.3.

Regards, Jeff.

The V5.4 schedule slipped, so I was able to include this fix in a later
baselevel of V5.4.  As was mentioned, there is also a patch for V5.3.

				-- Bob