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

[Richard J Maher]

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]

>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 · Accepted solution]

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]

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 :-)

[Richard J Maher]

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

Cheers Richard Maher

[Mark Corcoran]

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]

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]

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]

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.)