Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

 
SOLVED
Go to solution
Mark Corcoran
Frequent Advisor

RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

I wonder whether or not anyone else might have encountered this issue, and if so, whether or not it is something that can (readily) be fixed?

I've been trying to assist in debugging a memory leak issue in a number of processes.

On the development system, a debug version of one of the executables has been created.

If I run this /DEBUG in the "normal" debugger, I can hit G at the DBG prompt, and eventually the program springs into life.

However, in order to try and track down the memory leak, I want to use the Heap Analyzer.

It took me a while to work out how to do this -my reading of the debugger manual indicated that a server process needed to be created on the VMS node, with special debugger PC client software extracted from a saveset and installed on the PC (I later found out about SET DISPLAY /CREATE /NODE=pc_ip_addr /TRANS=TCPIP).

I can get the debugger display to be exported to the PC (DEBUG /KEEP after the SET DISPLAY), then the Heap Analyzer window opened up when I issue RUN /HEAP image.exe at the DBG prompt).

I click on the Start button on the H.A. window, and a lot of updates then take place to the screen.

I think these are memory allocations from various shareable images, before the code's main() function is called, mainly because I see very very fragmented allocation of memory by pthreads/DECthreads, and eventually at the debugger window I get %DEBUG-I-INITIAL and %DEBUG-I-NOTATMAIN messages).

I enter the GO command, and some more updates take place on the Heap Analyzer window, whilst the debug window shows Call Stack 0, LIB$INITIALIZE.

Eventually, the debug window shows a break(point) in the main() function, so I type GO again.

Now the program starts to perform its own initialisation, and using SMG draws outline boxes on my original telnet session that I issued the DEBUG /KEEP on.

Finally, the debug window shows that the program has handled an exception, and returned to the DBG prompt.

Looking in the log file that the process writes to, it shows the following messages:

%RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system
-RDB-I-TEXT, Error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]SECURESHR.EXE
, Shareable images must be installed to run privileged image
%DBAT-I-M010ATTDBSERR, Set Transaction Error - Attaching to database
%RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system
-RDB-I-TEXT, Error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]SECURESHR.EXE
, Shareable images must be installed to run privileged

I'm not sure if the DBAT is an RDB facility whose message is being output by the .EXE, or if it is the .EXE's own, and indicating in which "subsystem" an error occurred.

I'm a bit confused by the reference to SECURESHR.EXE though...

SECURESHR *is* an installed image:

$ pipe install list |sea sys$Input secureshr
SECURESHR;1 Open Hdr SharAddr Lnkbl Resid

SECURESHRP;1 Open Hdr SharAddr Prot Lnkbl Resid

SECURESHR_JACKET;1

After having had a quick rummage through comp.os.vms, it occurred to me that it might be a privilege issue, so I looked at the account settings in SYSUAF (not my own).


Authorized Privileges:
CMKRNL GROUP GRPNAM NETMBX PRMGBL SECURITY
SYSGBL SYSLCK SYSNAM TMPMBX WORLD
Default Privileges:
GROUP GRPNAM NETMBX PRMGBL SYSGBL SYSLCK
SYSNAM SYSPRV TMPMBX

I tried tearing everything down, then (for the purposes of testing) changing the account privs and defprivs to ALL.

I logged back in the modified account, used the SET DISPLAY, DEBUG /KEEP etc., and tried again.

Still no joy, exactly the same problem.

FWIW, version information:

$ @sys$library:rdb$shover
Current PROCESS Oracle Rdb environment is version V7.0-21 (MULTIVERSION)
Current SYSTEM Oracle Rdb environment is version V6.1-04 (STANDARD)
$ write sys$output f$getsyi("VERSION")
V7.2-1

Given that I don't have this problem when using the "normal" debugger, I would guess that this is some kind of "kept" debugger vs RDB (RTL) shareable image interaction issue.

If it is a version compatability issue, then it would help as ammunition to justify the case for upgrades (some other software that has to be upgraded across multiple platforms types has failed 4 times so far; there's even more reluctance to upgrade "base" (O/S and layered product) software as a result).

Any thoughts, anyone?
18 REPLIES 18
Richard J Maher
Trusted Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Hi Mark,

Rdb is known to give that/similar error when an executable has been installed with privileges and Rdb is trying to call out to a shareable image for an external function/procedure. (This is a completely erroneous restriction on Rdb's part but that's besides the point)

The usual "solution" is to give the user the matching privileges as those the image is installed with, but in this case you say the user was given default ALL privs (BTW does ALL grant SECURITY?)

What is the image being run and do you have a list of privs it was installed with?

Cheers Richard Maher
John Gillings
Honored Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Mark,

PRIVINSTAL messages are often inconsistent and confusing (I think it may be deliberatly obsuring useful information to make life hard for people trying to crack systems). For some reason SECURSHR and SECURSHRP get mentioned when it's actually another image entirely.

The logic here is that a privileged image is being activated dynamically, but, since you have DEBUG control, there may be a way to exploit the privileges. As Richard has suggested, give privilege to the process running the image, I'd also give them to the process running DEBUG for good measure.

Tracking the image can be tricky, try:

$ SET WATCH/CLASS=MAJOR

This may give a better indication. An even bigger hammer is to turn on the UAF AUDIT flag on the username running the image (but expect LOTS of output in the security journal!)

If you have all privileges, another approach to this type of problem is to try to avoid activating any installed images. Define logical names for everything you're likely to activate, including a version number, for example:

$ DEFINE LIBRTL SYS$SHARE:LIBRTL.EXE;

This will bypass the installed image. It may not work for all types of installed image, it will also completely change the memory layout of your running program, as RESID images will now be mapped to process space. This will probably affect your memory leaks.

(Lucky you have Richards attention, he has lots of experience debugging protected images, and running up against the arcane and confusing rules surrounding them)
A crucible of informative mistakes
Mark Corcoran
Frequent Advisor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Richard: Yup, I granted all privs to the account.

The account already had the SECURITY priv, but MOD /PRIV=ALL and /DEFPRIV=ALL does give SECURITY, even if the account doesn't already have it.

As regards what is the image being run and what privs is it installed with, I wonder if we're talking at cross-purposes...

An executable compiled and linked /DEBUG (and possibly other qualifiers, I don't know) was built by our off-shore suppliers.

Due to firewall restrictions, they cannot export the debugger display to their PCs, so I'm logging in to one of the developers' accounts, and running the executable for him (within the confines of the kept debugger and heap analyzer).

The executable itself is being run sort of in the same way as you might run an image - i.e. $ RUN FRED.EXE but within the kept debugger.

The exectuable is making some RDB call (unfortunately, not clear what, because the debugger can't see the sources; not sure if this is because logicals are not defined or are defined but point to the wrong location, or what).

The RDB call appears to encounter an exception, and the exception handler writes into the log file evidence suggesting it is a shareabile image access issue.

This is what refers to SECURESHR.EXE, and looking in VMSIMAGES.DAT, SECURESHR.EXE isn't specifically installed with any privileges:

/OPEN /HEADER /SHARED=ADDRESS_DATA /RESIDENT

Are you saying that it *should* in fact be installed /PRIV=(something_or_other) ?


John:
After modifying the account in SYSUAF to /PRIV=ALL/DEFPRIV=ALL, I've then logged into it, and run up the debugger, exporting the display to an X-term server on my PC, then issued RUN /HEAP debug_version_of_the_image.EXE

I'd already tried turning the AUDIT flag on for the account, in the hope that it might gave an indication as to some failure, but I couldn't see anything from the audit journal where the status was anything other than %SYSTEM-S-NORMAL).

I've tried the SET WATCH this morning (I was aware of it, had not thought to/forgotten to do this in my earlier tests).

Again, nothing really obvious, though whether or not the fact that the debug image being run uses SMG$ routines, and maybe results in me missing some of the SET WATCH output (because of scrollports etc.), I don't know.

If I bypass the installed SECURESHR.EXE (DEF /PROC SECURESHR SYS$SHARE:SECURESHR.EXE;1), the image being run in the debugger still indicates in the log file:

%RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system
-RDB-I-TEXT, Error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]SECURESHR.EXE
, Shareable images must be installed to run privileged image
%DBAT-I-M010ATTDBSERR, Set Transaction Error - Attaching to database
%RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system
-RDB-I-TEXT, Error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]SECURESHR.EXE
, Shareable images must be installed to run privileged


[Clutching at straws, when I defined SECURESHR to point to SYS$SHARE:SECURESHRP.EXE instead of SYS$SHARE:SECURESHR.EXE, the image reported in the log file stops being SECURESHR (or in this case, SECURESHRP), but RDMSHRP70.EXE instead]
H.Becker
Honored Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

>>>
-RDB-I-TEXT, Error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]SECURESHR.EXE
, Shareable images must be installed to run privileged image
<<<

It is an RDB message. The VMS PRIVINSTALL text is just "shareable images must be installed to run privileged image". You may see this at main image activation time as

$ run m
%DCL-W-ACTIMAGE, error activating image F
-CLI-E-IMGNAME, image file SEMMEL$DKA0:[HARTMUT]F.EXE;1
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
$

There is no problem with the filename in this error message. Once F is installed and a logical in exec mode points to it, the main program can be activated.

It looks like RDB dynamically activates a protected shareable image. It's very likely installed /open, so with SET WATCH/CLASS=MAJOR you will not see it.

I don't know anything about the heap analyzer. But I assume you have to define at least a couple of logicals pointing to images. Is there a logical for SECURESHR? make sure it is defined exactly as the file spec of the image which is installed, and that it is defined in exec mode.

Other than that, I would check with Oracle/RDB support.
Richard J Maher
Trusted Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

HI Mark,

Installing a shareable image with privs is useless. What I asked to see and you don't need any source code to obtaining is the full install listing of the image your're running. If it is a special debugger that I have not used that runs as the main executable and then somehow bootstraps to the target image then by all means show the install listing for the debugger as well.

Another thing that I'm sure you can do without the source is go into the database and do a SQL> SHOW FUNCTIONS or SHOW PROCEDURES. My guess is that there is an external function or external procedure in there that is calling out to a shareable image (may be as part of a virtual (COMPUTED BY) column). Again, just guessing but Rdb is known to place additional bullshit restrictions on shareable activation (over and above VMS's) but do make sure that all target shareables are in fact installed.

Cheers Richard Maher.
Mark Corcoran
Frequent Advisor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

>I don't know anything about the heap analyzer. But I assume you have to define at least a couple of logicals pointing to images.

According to the debugger manual, there's 3 ways of starting the Heap Analyzer, and of these, only one requires defining a logical (for LIBRTL, to point to an instrumented version of it), - and that is only for when the image is a shareable image.

The image being debugged isn't a shareable image; it's a normal image that you just RUN, but it makes an RDB call which fails, and the error information returned appears to suggest that the SECURESHR.EXE shareable image is the one with access issues.


>Is there a logical for SECURESHR?
Not normally, and according to the debugger manual, not required.


>Other than that, I would check with Oracle/RDB support.
A colleague is going to (belatedly) do that this morning.


>What I asked to see and you don't need any source code to obtaining is the full install listing of the image your're running

I think we must be talking at cross-purposes - the image I'm running isn't an installed image...

It's you bog-standard RUN image.EXE sort of image, but which makes calls to RDB, to access database tables.

It would appear that the attempt to connect to the database, is failing, and any secondary status returned by RDB, is indicating that it has a problem activating the SECURESHR.EXE installed image.


>If it is a special debugger that I have not used that runs as the main executable and then somehow bootstraps to the target image then by all means show the install listing for the debugger as well.

Analysing the channels open by a process which enters the command DEBUG /KEEP at the DCL prompt, shows that it accesses:

SYS$LIBRARY:DEBUGSHR.EXE
SYS$LIBRARY:LIBOTS.EXE
SYS$LIBRARY:LIBRTL.EXE
SYS$LIBRARY:LBRSHR.EXE
SYS$LIBRARY:DPML$SHR.EXE
SYS$SYSTEM:DCL.EXE
SYS$LIBRARY:DCLTABLES.EXE
SYS$LIBRARY:CMA$TIS_SHR.EXE
SYS$LIBRARY:DCXSHR.EXE
SYS$LIBRARY:DECC$SHR.EXE
SYS$LIBRARY:SMGSHR.EXE

You did ask for the full install listing of the debugger, but I'm not sure if you simply meant (in this case) DEBUGSHR.EXE or all of the other listed images.

I'm hoping DEBUGSHR.EXE will suffice...

xxxxx> install list /full sys$library:debugshr.exe

DISK$SYS_xxxxx:.EXE
DEBUGSHR;1 Open Hdr SharAddr Lnkbl
Entry access count = 1808
Current / Maximum shared = 6 / 15
Global section count = 5
Resident section count = 0000



>My guess is that there is an external function or external procedure in there that is calling out to a shareable image

I'll reserve judgement on this, because I'm not sure why it should be a function or procedure, rather than just an ESQLC call to an RDB/SQL function.

My RDB colleague is going to raise this with Oracle this morning, although I have a suspicion I know what they are going to say.

If I get anything meaningful from them, I'll update here.

On the other hand, if you think there's anything else I can provide here that might assist, I'd be only too happy to do so.
H.Becker
Honored Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

>>>
The image being debugged isn't a shareable image; it's a normal image that you just RUN, but it makes an RDB call which fails, and the error information returned appears to suggest that the SECURESHR.EXE shareable image is the one with access issues.
<<<
Which matches the initial description that the problem shows after you enter GO at the initial breakpoint in main. At the breakpoint, the image activation of the main image and all shareable images it depends on is already done.

Again, to me it looks like rdb activates another image. (I have no idea whether they use lib$fis or any other undocumented procedure.) That activation fails and rdb tells you that SECURESHR.EXE is not installed. I suspect rdb activates a protected shareable image, so I would try the documented (12.1 Starting a Heap Analyzer Session):

$ DEFINE/EXEC/NAME=CONFINE LIBRTL SYS$LIBRARY:LIBRTL_INSTRUMENTED

before starting the main image.
Richard J Maher
Trusted Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Hi Mark,

> On the other hand, if you think there's
> anything else I can provide here that
> might assist, I'd be only too happy to
> do so.

If the *executable* image being run is not a privileged image in the sense that it is not INSTALLed with privileges (even if they be /PRIV=NOALL) then this is indeed different.

I'd still like to see the results of
SQL> SHOW FUNCTIONS
SQL> SHOW PROCEDURES
on the database(s) in question. This will include simple stored SQL functions as well as any EXTERNAL 3GL code calls. If you can wittle the list down to just the external ones then you can do a SHOW FUNCTION MY_EXTERNAL and see what shareable image it invokes and what Logical Name translation it uses.

Yes Rdb uses LIB$FIS and the image-activator rules for logical names and installation etc are obviously followed but, once again, I am surprised that the mainline executable image is *not* installed with privs. How about showing us the $run myimage command followed by a $show log myimage and an $install list/all myimage

Cheers Richard Maher
Richard J Maher
Trusted Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

btw, SYS$SHARE:RDB$COSIP.EXE is a known vector for SECURESHR.EXE and SECURESHRP.EXE and IIRC (electricity has gone up 50% here and I don't just leave my VMS boxes running any more :-) it is a UWSS that does the username/paswword checking and should be installed protected by Rdb system (or monitor?) startup.

Either way, make sure all 3 of the above are installed.

Cheers Richard Maher
Richard J Maher
Trusted Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

One last question/straw:- Is there any rdb$remote in action here? i.e. attaching to a database over the network/remote-process?

Cheers Richard maher

PS. I see you've shown both secure and securesh are both installed but check rdb$cosip anyway.
Mark Corcoran
Frequent Advisor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

>Again, to me it looks like rdb activates another image. (I have no idea whether they use lib$fis or any other undocumented procedure.)

The response from Oracle (lurking in the shadows here ;-)) is that RDB does perform dynamic activation of privileged images.


>I would try the documented (12.1 Starting a Heap Analyzer Session)

As best as I understand, this is only required if the image being debugged (RUN /HEAP imagename.EXE) is intended to be a shareable image.

However, I've defined LIBRTL /EXEC to point to the instrumented version, and it makes no difference - the error still occurs :-(


>If the *executable* image being run is not a privileged image in the sense that it is not INSTALLed with privileges (even if they be /PRIV=NOALL) then this is indeed different.

Yes Richard, indeed, it is not a privileged image in that sense.

There are no functions, but there are 3 procedures, only 2 of which are external:

SQL> show procedure get_symbol
Procedure name is: GET_SYMBOL
Procedure ID is: 4
External Location is: SYS$SHARE:LIBRTL.EXE
Entry Point is: LIB$GET_SYMBOL
Bind on Client Site
Bind Scope Connect
Comment: Gets DCL symbol string value
Language is: GENERAL
GENERAL parameter passing style used
Number of parameters is: 3

Data Type
---------

SYMBOL VARCHAR(255)
Parameter position is 1
Parameter is IN (read)
Parameter is passed by DESCRIPTOR

VALUE_STR VARCHAR(255)
Parameter position is 2
Parameter is OUT (write)
Parameter is passed by DESCRIPTOR

VALUE_STR_LEN SMALLINT
Parameter position is 3
Parameter is IN/OUT (modify)
Parameter is passed by REFERENCE


SQL> show procedure set_symbol
Procedure name is: SET_SYMBOL
Procedure ID is: 3
External Location is: SYS$SHARE:LIBRTL.EXE
Entry Point is: LIB$SET_SYMBOL
Bind on Client Site
Bind Scope Connect
Comment: Sets DCL symbol with string value
Language is: GENERAL
GENERAL parameter passing style used
Number of parameters is: 2

Data Type
---------

SYMBOL VARCHAR(255)
Parameter position is 1
Parameter is IN (read)
Parameter is passed by DESCRIPTOR

VALUE_STR VARCHAR(255)
Parameter position is 2
Parameter is IN (read)
Parameter is passed by DESCRIPTOR



>How about showing us the $run myimage command followed by a $show log myimage and an $install list/all myimage

Not sure if you're referring to the run command required, or the output of the command, and whether or not you mean the RUN /HEAP command issued at the "kept" debugger's DBG prompt, or just running it from DCL.

Suffice it to say that the image does not have a logical name associated with it, nor is it installed as a shareable image.

However, having just checked on the production system, the non-debug version of the image is actually installed (my apologies - I had wrongly assumed that it wwasn't).

An INSTALL LIST /FULL of it shows the following:
Open Hdr Shared Prv
Entry access count = 2954
Current / Maximum shared = 120 / 147
Global section count = 2
Privileges = TMPMBX NETMBX SYSLCK
Authorized = TMPMBX NETMBX SYSLCK



>Either way, make sure all 3 of the above are installed.
I've had a look, and SECURESHR, SECURESHRP and RDB$COSIP are all installed images:

xxxxx> install list sys$share:rdb$COSIP.EXE

DISK$SYS_XXXXX:.EXE
RDB$COSIP;8 Open Hdr Shared Prot Lnkbl


xxxxx> install list sys$share:secureshr.exe

DISK$SYS_XXXXX:.EXE
SECURESHR;1 Open Hdr SharAddr Lnkbl Resid


xxxxx> install list sys$share:secureshrp.exe

DISK$SYS_XXXXX:.EXE
SECURESHRP;1 Open Hdr SharAddr Prot Lnkbl Resid



>Is there any rdb$remote in action here? i.e. attaching to a database over the network/remote-process?

Not as far as I am aware, unless for some mind-boggling reason, it goes "out" over the network, just to come back into the same node.

I'll do my best to check this on the production system, and report back.



The only other thing I'd say, which I hadn't previously noticed (because the debug X-window I had only had a few lines in it, so things scrolled off), is that you before the exception handler reports the exception, the following message is output in the debug X-window (not the original Telnet session):

%DEBUG-I-DYNIMGSET, setting image LIBRTL

The time between the "setting image" message being output above, and the message from the exception handler, is a few milliseconds.

So, I can't really tell if the problem is really LIBRTL (not helped by a misreporting of SECURESHR)...

I don't know whether or not to expect a confirmation message that the image has been activated (i.e. absence of one indicates that LIBRTL has not been set/activated), or only expect another message if the image setting/activation fails.

[I don't see an explicit message to indicate that image setting/activation fails, but I don't know if this is because the exception handler has kicked in, in the meantime]
H.Becker
Honored Contributor
Solution

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

From what I read the following happens. You start your application with the run/heap from the debugger. That results in LIBRTL_INSTRUMENTED being activated instead. (You can check that with SDA in the DBGK$$nnn process.) After GO the protected image is activated, it is linked with LIBRTL which as the instrumented version is already mapped. But that one isn't installed.

Can you/do you want to try with
$ install add/share/open SYS$LIBRARY:LIBRTL_INSTRUMENTED
?
It seems this image isn't installed by default.

If you want to start the heap analyzer from the DCL command line, you need the logical and you need the image installed. It looks like this is missing in the documentation I looked at or hidden in a setup command procedure, which I do not know.
John Gillings
Honored Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Mark,


>>Is there any rdb$remote in action here?
>
>Not as far as I am aware, unless for some
>mind-boggling reason, it goes "out" over
>the network, just to come back into the
>same node.

If Helmut's suggestion of installing LIBRTL_INSTRUMENTED doesn't work (though I expect it will), maybe the next thing to attempt is to force remote access to the database. That should get all the data base stuff out your process space. It's a fair bet that your memory leak doesn't involve Rdb, so it may make diagnosis easier. On the other hand, if the leak goes away, you'll have evidence to give to Oracle that it's their problem :-)
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Yep, I vote for Helmut's (Hartmut's?) answer as well. (I've certainly nhever heard of LIBRTL_INSTRUMENTED)

Cheers Richard Maher
Mark Corcoran
Frequent Advisor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Thanks everyone for their assistance- I've finally managed to make progress - the installing of LIBRTL_INSTRUMENTED does indeed prevent the image activation failure, or at least, so far.

My next problem is that whilst running under the debugger, and with the heap analyzer having to be updated as code execution proceeds, the actual execution rate is slow*, so I'm sat here waiting to see if the image will eventually give me a command prompt (it's clearly doing lots of initialisation at the moment).

I've had two attempts at this so far, where the first one had to be aborted because of the debugger reporting an internal error (I forget the specific message) and the heap analyzer updates being sent instead to by Telnet session (from where I'd issued the DEBUG /KEEP command).

The second attempt appeared to be some comms timeout between the Heap Analyzer X-window and the node on which it was running (or maybe even the debug X-window, because when I eventually managed to kill the hung Heap Analyzer window, it also took my debug X-window and my X-term server with it.

I'm running a third attempt at the moment, with the check box/radio-button like control for "Sync" in the Heap Analyzer window checked/disabled.

This seems to reduce (but not eliminate) the updates to the Heap Analyzer window - though I'm not sure if/when I get the command prompt from the image, if I uncheck/enable the "Sync" control, it will do a single-shot refresh at that point.

*It clearly allocates a lot of memory in a piecemeal fashion - on my second attempt, the Heap Analyzer had indicated that there were about 120,000 "Segments", although the actual pages shown to be used by SHOW SYSTEM /PROCESS=, was about 4000 (and - slowly - increasing).

I suspect that this won't get anywhere near completion of the initialisation routines by the time I need to leave (running on a laptop, no Kensington lock for whatever good that would do), so will need to try a fourth attempt early tomorrow morning.

In the meantime, I've been looking at another issue which I found whilst investigating this problem, so look out for another post from me :-)
Mark Corcoran
Frequent Advisor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

I would like to thank H.Becker especially, but I'm not sure of the first name (seems others perhaps don't know either).

I'm not keen on just calling you "H" - there is an ex-colleague we used to call that, but simply because a lot of people had difficulty pronouncing her name (that's the Gaelic influence for you...)

Mark
Peter T Jackson
Occasional Visitor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

I am the person at Oracle who has been handling this.

Note that Rdb does not say that SECURESHR.EXE is not installed. It says that that was the image it was trying to activate when it got the error:
-RDB-I-TEXT, Error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]SECURESHR.EXE

The RDB-I-TEXT message seems to have been added since this issue was last raised (in 2001). If you have access to My Oracle Support then document 134109.1 is the one that discusses it. I will be looking at enhancing that.

Though the image that returned the error on activation was SECURESHR it can be caused by an image that SECURESHR calls (as was the case here). Rdb does not know what image that was. I do not believe that VMS returns that information.
H.Becker
Honored Contributor

Re: RDB/SECURESHR image activation problem with "kept" debugger & heap analyzer

Activation of the image SECURESHR is not a problem, the image is installed. It depends on:

$ shiml sys$share:secureshr.exe
recursive SHareable IMage dependency List (Alpha), version 1.1
.[ -> Translated Logical Name ] Required Match: ID [ / Actual match: ID ]
.[ (self) - Self Reference; (dnf) - Duplicate, Not Followed ]

SECURESHRP - MATLEQ: 1,4 / MATLEQ: 1,4
....SECURESHRP (self)
....SYS$BASE_IMAGE
....SYS$PUBLIC_VECTORS
LIBRTL - MATLEQ: 1,1 / MATLEQ: 1,1
....SYS$PUBLIC_VECTORS (dnf)
LIBOTS - MATLEQ: 1,3 / MATLEQ: 1,3
....SYS$PUBLIC_VECTORS (dnf)
....SYS$BASE_IMAGE (dnf)
....SYS$PUBLIC_VECTORS (dnf)

where SECURESHRP is installed as a protected shareable image, which does not depend on LIBRTL.

In this thread, the problem shows for protected (shareable) images, which depend on LIBRTL and where LIBRTL is defined as SYS$LIBRARY:LIBRTL_INSTRUMENTED, which
is not installed.

I don't know what Rdb is activating, with SECURESHR being installed (in this
case and by default) it can't be that image.

When dynamically activating an image with lib$fis, the cause of an activation failure is signaled by lib$fis. For example, if you want to activate A.EXE, which depends on S.EXE and S.EXE causes an activation problem, "%LIB-E-ACTIMAGE, error activating image DSA20:[SYS1.SYSCOMMON.][SYSLIB]S.EXE;" is signaled. (And yes, in a few cases the name of the image can be misleading.)