[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

204.0. "Process hangs in LEF state " by NIXFIX::LOBSANG (A good bug is hard to find) Mon Feb 17 1997 15:53

I have a process that hangs in LEF state. On going through ther archived
VMSNotes files I came across Note 3150.* in VMSNotes_V10 which deals with
Processes that hang when $UPDSECW is called without specifying an event
flag and iosb. However, it is not clear from these Notes if this pertains
to both $UPDSEC and $UPDSECW. On reading the System Services documentation
regarding $UPDSEC, it seems that this would be the case for both $UPDSEC
and $UPDSECW since in $UPDSECW, if I am not mistaken, a $SYNCH is 
implicitly called with event flag 0 if no event flag is specified. 

The Notes in VMSNotes_V10 described how it was possible for a process
to hang upon calling $UPDSECW if no event flag is specified. It seems
that it is possible for another event to clear event flag 0 before
$UPDSECW reads it thus resulting in the Process hanging in a LEF state.

Upon reading the code for the hung process, I see that a call to $UPDSECW
is made with no event flag and iosb being specified. Could this be the
reason that the process hangs in LEF state. This happens only once in a
rare while - twice within the past six months and only when the application
is very, very busy handling lots of transactions. In the code it looks like
the $UPDSECW is the culprit because using SDA I could ascertain that the
process had taken out a lock on a resource that preceeds the call to
$UPDSECW and the actions following $UPDSECW do not appear to have been
executed. Would the use of $UPDSECW in this manner be the the reason
why the process remains hung in the LEF state ?


Lobsang
T.RTitleUserPersonal
Name		DateLines
204.1Use SDA or SHOW PROCESS, Locate The Hang...XDELTA::HOFFMANSteve, OpenVMS EngineeringMon Feb 17 1997 16:3015
   LEF is often a normal state.

   Flakey application behaviour is usually due to incorrect use of the
   event flags, use of event flag zero, incorrect declaration or failure
   to use an IOSB whenever one is permitted, failure to synchronize the
   completion of asycnhronous calls via sys$synch or similar, incorrect
   or unintended sharing of event flags and/or IOSBs, or failure to check
   all system service or run-time return status codes...

   When the process is wedged, use SDA or SHOW PROCESS to try to determine
   what was going on in the context of the process -- you may be able to
   locate the PC where the process is wedged, and back-track to the user
   (or system) code that is involved in the hang.
204.2AUSS::GARSONDECcharity Program OfficeMon Feb 17 1997 21:3627
re .0               
    
>Processes that hang when $UPDSECW is called without specifying an event
>flag and iosb.
    
    That can happen. In fact it can happen when any of the $*W services is
    called and the IOSB is not specified and the EFN is not specified and
    there is inopportune asynchronous activity that uses event flag 0
    (explicitly or implicitly).
    
    Later versions of VMS allow you to avoid event flag usage completely.
    Traditionally though you are always using an event flag whether you
    like it or not.
    
>     However, it is not clear from these Notes if this pertains
>to both $UPDSEC and $UPDSECW.
    
    It can't happen with $UPDSEC because that service does not wait. It
    could happen if you then subsequently explicitly issued a call to
    $WAITFR or to $SYNCH.

    It really doesn't matter whether these discussions explain your observed
    behaviour. Put in an IOSB. But make sure that the lifetime of the IOSB
    variable exceeds the lifetime of its usage e.g. static if you have to.
    
    Having done that ensure that each concurrent asynchronous activity has a
    unique non-zero event flag.
204.3UTRTSC::utoras-198-48-93.uto.dec.com::JurVanDerBurgChange mode to Panic!Tue Feb 18 1997 01:275
If you don't specify an iosb for the call to $updsecw, then how do you know that 
the call completed without any errors? Right, you don't.

Jur.
204.4Need help with SDANIXFIX::LOBSANGA good bug is hard to findTue Feb 18 1997 13:40112
The process in question hung today in the LEF state. I was able to use SDA
to get some information but being not very proficient in SDA was unable to
pinpoint the place where the process was hung. I used some commands that
I saw in some SDA examples to exame some of the instructions and it seems
that SYS$SYNCH is in action but I could not find out if SYS$SYNCH was called
by SYS$UPDSECW. I have attached below the output from the SDA commands
that I used. The <CR>s are a result of cut and paste operations that I used
to save the output from a terminal emulator. Can someone verify if the
process is hannging in $SYNCH ? If so, how do I find out in SDA which
event flag $SYNCH is waitng for and if $SYNCH has been called by $UPDSECW
and if the evnt flag is set or cleared ???

Lobsang

SDA> sho stack/user
Process stacks
--------------
Current operating stack (USER):
 
                 7FEC515C  00000004
                 7FEC5160  0014EB78
                 7FEC5164  0FFC0000
                 7FEC5168  7FEC523C
                 7FEC516C  7FEC51B4
                 7FEC5170  8AC1635F      EVENT_FLAGS_AND_ASTS+0055F
                 7FEC5174  00233BFF
                 7FEC5178  7FFEFEE0      CTL$GL_IPAGEFL
 
          SP =>  7FEC517C  00000000
                 7FEC5180  00000000
                 7FEC5184  207C0000
                 7FEC5188  7FEC523C
                 7FEC518C  7FEC51B4
                 7FEC5190  80000343      EXE$WAIT_FORM+00023
                 7FEC5194  00000001
                 7FEC5198  7FFEFEE0      CTL$GL_IPAGEFL
                 7FEC519C  8CAEA140      PCB
                 7FEC51A0  7FF4FA00
                 7FEC51A4  FFFFFFFF      PR$_XSID_N8NNN
                 7FEC51A8  00000002
                 7FEC51AC  00000000
                 7FEC51B0  00000000
                 7FEC51B4  00000000
                 7FEC51B8  01FC0020
                 7FEC51BC  7FEC52B0
                 7FEC51C0  7FEC5274
                 7FEC51C4  00223D11
                 7FEC51C8  00000001
                 7FEC51CC  7FEC5B01
                 7FEC51D0  00000001
                 7FEC51D4  00000000
                 7FEC51D8  00000001
                 7FEC51DC  00000400      IRP$M_MBXIO
                 7FEC51E0  7FEC51E4
                 7FEC51E4  00000005
                 7FEC51E8  00000001
                 7FEC51EC  00000001
                 7FEC51F0  00000000
                 7FEC51F4  7FFEE450      SYS$SYNCH+00010
                 7FEC51F8  03C00004
                 7FEC51FC  00546081
                 7FEC5200  00000000
                 7FEC5204  0FFC0020
                 7FEC5208  7FEC52B4
                 7FEC520C  7FEC5288
                 7FEC5210  0022289B
                 7FEC5214  00000001
                 7FEC5218  7FEC5B01
                 7FEC521C  00000000
                 7FEC5220  00000000
                 7FEC5224  7FEC5330
                 7FEC5228  00000400      IRP$M_MBXIO
                 7FEC522C  0000016C
                 7FEC5230  7FF28680

		............
		............

SDA>sho call
Call Frame Information
----------------------
         Call Frame Generated by CALLS Instruction
 
Condition Handler        7FEC5180  00000000
SP Align Bits = 00       7FEC5184  207C0000
   Saved  AP             7FEC5188  7FEC523C
   Saved  FP             7FEC518C  7FEC51B4
   Return PC             7FEC5190  80000343      EXE$WAIT_FORM+00023
         R2              7FEC5194  00000001
         R3              7FEC5198  7FFEFEE0      CTL$GL_IPAGEFL
         R4              7FEC519C  8CAEA140      PCB
         R5              7FEC51A0  7FF4FA00
         R6              7FEC51A4  FFFFFFFF      PR$_XSID_N8NNN
Align Stack by 0 Bytes =>
Argument List            7FEC51A8  00000002
                         7FEC51AC  00000000
                         7FEC51B0  00000000
SDA> e/i 80000343-20;20
EXE$WAIT_FORM+00003:  HALT
EXE$WAIT_FORM+00004:  BLBC    R0,EXE$WAIT_FORM+00029
EXE$WAIT_FORM+00007:  MOVL    R0,R2
EXE$WAIT_FORM+0000A:  MOVQ    14(AP),-(SP)
EXE$WAIT_FORM+0000E:  BRB     EXE$WAIT_FORM+0001C
EXE$WAIT_FORM+00010:  BLBC    R0,EXE$WAIT_FORM+00029
EXE$WAIT_FORM+00013:  MOVL    R0,R2
EXE$WAIT_FORM+00016:  PUSHL   14(AP)
EXE$WAIT_FORM+00019:  PUSHL   04(AP)
EXE$WAIT_FORM+0001C:  CALLS   #02,@#EXE$SYNCH
EXE$WAIT_FORM+00023:  BLBC    R0,EXE$WAIT_FORM+00029
204.5fix the bug, always use an IOSBGIDDAY::GILLINGSa crucible of informative mistakesTue Feb 18 1997 17:4114
  Lobsang,

>Align Stack by 0 Bytes =>
>Argument List            7FEC51A8  00000002
>                         7FEC51AC  00000000
>                         7FEC51B0  00000000

    If this is the argument to SYS$SYNCH, then you're using event flag 0 with
  no IOSB. This is a LEF hang looking for a place to happen. I would strongly
  recommend you stop attempting to repeat the diagnosis of this problem
  performed many times before, and simply correct your program. I don't care
  what the manual says, the IOSB argument is *NOT* optional. 

						John Gillings, Sydney CSC
204.6Code already fixedATZIS1::GYALPOWed Feb 19 1997 03:019
    John,
    
    Thanks for your viewpoint. I have already fixed the problem in the code
    by using an iosb and an event flag  in the call to $UPDSECW. I just
    wanted to be sure that this was the cause of this particular hang. I
    know that the error in the code can/will cause a process to hang.
    
    Lobsang