[Info-vax] hung program location

[VAXman- at SendSpamHere.ORG]

In article <e+Gu+POoIK2S at eisner.encompasserve.org>, koehler at eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <fd1c789e-3d0f-439a-a9e1-fe6ea1d0ba62 at x13g2000vby.googlegroups.com>, Tom Adams <w.tom.adams at gmail.com> writes:
>> 
>> The PC is 80141918 (as shown on show proc/cont)  The process
>> is in HIB when it's at that address.
>
>   OK, that's the low 32 bits of a system space address.  Most likely
>   it points to the system routine that puts the process in HIB.

Already determined it's in $HIBER support code.

I can offer to narrow thing down for him.  If he has the LINKER .MAPs and
compiler /MACHINE .LIStings, he can use SDA.

$ ANALYZE/SYSTEM
SDA> READ/EXECUTIVE
SDA> SET PROCESS/INDEX=<PID-of-hung-process>
SDA> SHOW CALLS/ALL

That will trace the calls which lead to the invocation of the $HIBER.  If
he has the .MAPs and .LIStings, he should be able to figure out where in 
the code the LIB$WAIT was invoked.

However, I'm in agreement with Hoff.  There's some latent timing issue or
a misuse of asynchronous features.  One of the things I'd look at are the
$QIO IOSBs.  If these $QIOs are called with the SAME IOSB, there's hell to
pay!  These should all have their own unique IOSB.  If no EFN is specified,
(ie. NOT EFN$C_ENF) then EFN 0 will be used.  This is yet another potential
area to explore.  I'd be sure to use unique IOSBs and EFN$C_ENF unless the
EFN triggers/signals something else significant in the code.

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

Well I speak to machines with the voice of humanity.