[Info-vax] The PWAIT tool.

[VAXman- at SendSpamHere.ORG]

In article <D89xm.11973$U5.164487 at newsb.telia.net>, =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm at telia.com> writes:
>IanMiller wrote:
>> On 1 Oct, 15:54, Jan-Erik Söderholm <jan-erik.soderh... at telia.com>
>> wrote:
>>> VAXman- @SendSpamHere.ORG wrote:
>>>> In article <jW2xm.11964$U5.164... at newsb.telia.net>, =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderh... at telia.com> writes:
>>>>> Hi.
>>>>> I have a process that is in "MUTEX" state.
>>>>> I found some tool called PWAIT and tried that.
>>>>> It runs inside of SDA (after DEFINE PWAIT$SDA to point
>>>>> to the PWAIT$SDA.EXE) like this :
>>>>> $ ana/sys
>>>>> OpenVMS system analyzer
>>>>> SDA> pwait SYMBIONT_669
>>>>> PWAIT V1.0 (c) 2004, Ian Miller (mil... at encompasserve.org)
>>>>> built on VMS V8.2
>>>>> reading symbol tables
>>>>> %SDA-W-LINKTIMEMISM, link time of SYS$COMMON:[SYS$LDR]ERRORLOG.STB;1
>>>>> ( 3-DEC-2004 09:50) does not match link time of image in system
>>>>> (18-JUL-2006 14:39)
>>>>> Process PID 000261DC name SYMBIONT_669 No. Threads 1
>>>>> Thread 0: state MWAIT AST pending KU active (none) blocked (none)
>>>> Mutext WAIT state with AST pending (I'm going to assume that Ian's
>>>> KU means a special-kernel USER mode AST).
>>>>> Process has been waiting for 00:00:00.18
>>>>> Process thread resource wait is ENABLED
>>>>> Analyzing process locks
>>>>>         Process owns no locks
>>>>>         waiting for mutex 824A7E00
>>>> That's the address of the MUTEX.
>>>> You might try to EXAMINE 824A7E00 or MAP 824A7E00.  It might lend some
>>>> more insight as to what the mutex is that it is waiting on.
>>> SDA> examine 824A7E00
>>> FFFFFFFF.824A7E00:  FF67B470.FF67B470   "p´g.p´g."
>>> SDA> map 824A7E00
>>> %SDA-E-NOTINIMAGE, address (FFFFFFFF.824A7E00) not within a
>>>                     system or user image
>>> SDA>
>>>
>>> The process has the following open files :
>>>
>>> $ pipe sh dev sys$sysdevice/file | sea sys$pipe SYMBIONT_669
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSMSG]DCPS$MSG.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSEXE]DCPS$SMB.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSLIB]SMBSRVSHR.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSLIB]CMA$OPEN_LIB_SHR.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSLIB]CMA$LIB_SHR.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSLIB]DCPS$SMBSHR.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSLIB]DCPS$BE_SERIAL.EXE;1
>>> SYMBIONT_669    000261DC  [VMS$COMMON.SYSLIB]TRN$ANSI_PS.EXE;1
>>>
>>> so it's an DCPS symbiont, it that helps...
>>>
>>> When I try SHO CHAN in SDA, SDA hangs. Had to stop/id
>>> from another session.
>> 
>> 
>> have you done READ/EXEC, READ SYSDEF, SET PROCESS in SDA to help SDA
>> turn the address of the mutex into a symbol?
>> AST Pending: KU - means the ast pending longword in the KTB had the
>> kernel and user mode bits set.
>> 
>> PWAIT$SDA - is saying MUTEX wait as the EFWM in the KTB is not
>> pointing to the JIB
>
>Hi.
>
>READ/EXEC gave :
>
>SDA> read/exec
>%SDA-W-LINKTIMEMISM, link time of SYS$COMMON:[SYS$LDR]ERRORLOG.STB;1
>( 3-DEC-2004 09:50) does not match link time of image in system
>(18-JUL-2006 14:39)
>
>Actualy the same message that PWAIT gave (as seen above)...
>
>$ HELP /MESS says :
>
>$ h /mess LINKTIMEMISM
>
>  LINKTIMEMISM,  link time of 'file-name' ('dd-mmm-yy hh:mm') does
>                 not match link time of image in 'target' ('dd-mmm-yy
>                 hh:mm')
>
>   Facility:     SDA, System Dump Analyzer
>
>   Explanation:  The copy of SYS$BASE_IMAGE.EXE used by SDA to build
>                 its symbol table is not the same version as that used
>                 when the system being analyzed was booted.
>
>                 This message is only a warning. SDA continues unless the
>                 mismatch causes an unrecoverable error.
>
>   User Action:  Ensure that logical name ALPHA$LOADABLE_IMAGES points
>                 to a directory containing the same version of
>                 SYS$BASE_IMAGE.EXE that was used when the system
>                 being analyzed was booted.
>
>
>Right, so :
>
>$ dir SYS$COMMON:[SYS$LDR]ERRORLOG.STB
>
>Directory SYS$COMMON:[SYS$LDR]
>
>ERRORLOG.STB;1   44/54        3-DEC-2004 09:50:59.75
>
>and :
>
>$ sh log  ALPHA$LOADABLE_IMAGES
>    "ALPHA$LOADABLE_IMAGES" = "SYS$SYSROOT:[SYS$LDR]" (LNM$SYSTEM_TABLE)
>
>$ dir  ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE
>
>Directory SYS$COMMON:[SYS$LDR]
>
>SYS$BASE_IMAGE.EXE;2      993/1008      6-JAN-2009 15:30:56.84
>SYS$BASE_IMAGE.EXE;1      993/1008     15-DEC-2006 07:47:41.45
>
>Total of 2 files, 1986/2016 blocks.
>
>$ write sys$output f$getsyi("boottime")
>20-JUL-2009 10:05:06.00
>
>
>So, is there some trouble here ? Maybe I should delete
>SYS$BASE_IMAGE.EXE;1 and rename the ;2 => ;1 ?
>
>
>READ SYSDEF seems to have worked OK though...
>
>SDA> read sysdef
>SDA>
>
>Anyway, these two "reads" and the "set proc" didn't change
>the output from the PWAIT command.

BUt they might change the EXAMINE or MAP.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"