[Info-vax] The PWAIT tool.
Jan-Erik Söderholm
jan-erik.soderholm at telia.com
Thu Oct 1 17:26:59 EDT 2009
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.
More information about the Info-vax
mailing list