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

Conference clt::rtl

Title:	OpenVMS Run-Time Libraries
Notice:	Routines documented in the Run-Time Library volumes covered here
Moderator:	LOWFAT::DIETER

Created:	Sat Jan 25 1986
Last Modified:	Wed May 28 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	966
Total number of notes:	4598

965.0. "LIB$FIND_IMAGE_SYMBOL hangs in HIB state User ASTs disabled" by GIDDAY::GILLINGS (a crucible of informative mistakes) Wed May 21 1997 03:01

  A customer has reported that the version of SNS$SHR distributed in ECO kit
  SNSVAXECO03022 cannot be activated with LIB$FIND_IMAGE_SYMBOL. This is
  completely repeatable with the following FORTRAN program:

        CALL LIB$FIND_IMAGE_SYMBOL('SNS$SHR','SNS$DELETE_MESSAGE',i)
	END

  The process hangs in HIB state in the call to $IMGFIX with user mode ASTs
  disabled. There are no pending ASTs or I/Os.

State                       HIB      Termination mailbox          0000
Current priority                9    AST's enabled                KES
Base priority                   4    AST's active                 NONE


  From V6.2 results disk [V62.LIBRTL.LIS]LIBFNDIMG.LIS

;   0831  3         IF .status
;   0832  3         THEN
;   0833  3             !+
;   0834  3             ! Perform image fixup operations.
;   0835  3             !-
;   0836  3
;   0837  3             status = $IMGFIX;
;   0838  3

  The image in question is SNS$SHR with image ident 2.2-11. Since it's linked
  by the installation procedure, the link date/time will vary. (I chopped 
  the LINK command out of KITINSTAL.COM since I don't have the product
  installed on my systems).

  I ran the test program on OpenVMS/VAX V6.1, V6.2 and V7.0 with the same
  results.

  Test files are available on node BANDI (59.543):

$ dir bandi::*sns*

Directory BANDI::SYS$SPECIFIC:[FAL$SERVER]

FIS_CALL_SNS$SHR.EXE;2                  SNS$SHR.EXE;3

Total of 2 files.

  just DEFINE SNS$SHR to point to the shareable image SNS$SHR.EXE and run
  FIS_CALL_SNS$SHR.

  I'm not sure if this should be in RTL or VMSNOTES.  Any ideas?

						John Gillings, Sydney CSC

T.R	Title	User	Personal Name	Date	Lines
965.1	No answers, just crumbs	WTFN::SCALES	Despair is appropriate and inevitable.	`Wed May 21 1997 12:09`	33
	G'day, John! (;-) I'm afraid I can't offer an answer (to any of the questions), but I can provide a few crumbs... I believe that LIB$FIND_IMAGE_SYMBOL disables ASTs itself (in an attempt to avoid reentrancy and similar problems -- it maintains a database of currently activated images...), so that should explain why you're seeing ASTs disabled. I'm struck by the fact that you're seeing the thing hung in the HIB state -- I wouldn't have expected $IMGFIX to call $HIBER. However, SNS$SHR appears to have a dependency on the ADA RTL, and I wouldn't be surprised at all if the Ada tasking run-time support called $HIBER when there was nothing else for it to do (i.e., when the main task and all others (or which there are probably none here) are blocked). I don't know how well ADARTL tollerates being dynamically activated or how well it operates with ASTs turned off. I believe that ADARTL has a LIB$INITIALIZE psect which would be executed during the call to $IMGFIX (if I remember correctly), and it -could- be that this is where the call to $HIBER is taking place. I'd recommend taking a look at the "current user stack", once the program is hanging, and see whether it looks like the default (P1 space) stack or whether it looks like something else; I presume that the thing is hanging in USER mode, can you tell what frames are on the stack? (You might try linking your test program against ADARTL, and see if that improves the situation -- doing this would cause ADARTL to be loaded with the main image instead of later with SNS (with ASTs disabled).) Otherwise, you'll need to take a trip through the sources for L$FIS and $IMGFIX looking for calls to $HIBER... :-p Webb
965.2	looks like you can't get there from here	GIDDAY::GILLINGS	a crucible of informative mistakes	`Wed May 21 1997 20:52`	41
	Webb, > but I can provide a few crumbs... I think you've cracked it. > (You might try linking your test program against ADARTL, and see if that >improves the situation -- doing this would cause ADARTL to be loaded with the >main image instead of later with SNS (with ASTs disabled).) I'd already tried that (thinking along similar lines about tasking) with no difference in behaviour, but your comment about LIB$INITIALIZE has pointed me to: LIB$INITIALIZE 0001AA00 0001AA97 00000098 ( 152.) LONG 2 NOPIC,USR,CON,REL,GBL,NOSHR,NOEXE, RD,NOWRT,NOVEC ADA$ELAB_SNS_SHR 0001AA00 0001AA97 00000098 ( 152.) LONG 2 So, there's an ADA elaboration for the SNS module which needs to be executed at activation time. Nothing short of linking directly with the shareable image will resolve that. I don't think there's any way to make it work (I even tried calling SYS$WAKE just before LIB$FIS, still no go :-(. >Otherwise, you'll need to take a trip through the sources for L$FIS and >$IMGFIX looking for calls to $HIBER... :-p Already been there, predictably there are no calls to $HIBER. >I'd recommend taking a look at the "current user stack" Of course!, that proves it: Process stacks -------------- Current operating stack (USER): 0007BDA4 00000000 0007BDA8 00000000 0007BDAC 00000000 QED. John Gillings, Sydney CSC
965.3		SPECXN::DERAMO	Dan D'Eramo	`Thu May 22 1997 11:24`	8
	I believe the base note author has already seen these but in case anyone reads through here in the future, a seeminlgy similar issue is discussed in TURRIS::C_PLUS_PLUS topic 3583 VAXAXP::VMSNOTES topic 626 Dan