Operating System - OpenVMS
1748183 Members
3423 Online
108759 Solutions
New Discussion юеВ

Re: Error activating image ...

 
SOLVED
Go to solution
Klaus Heim
Advisor

Error activating image ...

We ported our Appliction from AXP to IA64. In one of our batch procedures we got the following error message:

$ DISPO_RETOUR :== $KLS$SYSTEM:SIN$DISPO_RETOUR
$ DISPO_RETOUR SO_AUS_NN
%DCL-W-ACTIMAGE, error activating image TPSHR
-CLI-E-IMGNAME, image file DSA0:[TPLIB]TPSHR.EXE;5
-LOADER-E-BADIMGOFF, image offset not within any image section

This is mystery to us, because the image DISPO_RETOUR runs with different input parameters without any error messages. And the shared library TPSHR is ativated by nearly every image from the batch procedure - also without any error message.

There are also the following messages:

-LOADER-E-BAD_DYNTBL, image format error - illformed dynamic table
or
-LOADER-E-BADIMGRELA, unexpected rela type for image

The errors occurs very rarely. However only in our midnight job - which terminates abnormally.

34 REPLIES 34
Hoff
Honored Contributor

Re: Error activating image ...

Check for bogus logical names for the image; make sure you're invoking the image you think you're invoking. (Invoking a DIRECTORY /FILE of the image just before you invoke the image itself is probably a sufficient checksum to determine that.)

I'd also check constituent shareable images, just for completeness.

Check process quotas. When the process quotas are insufficient, the image activation process can be unable to generate decent error messages.

Check that you're current on patches. (There were some bugs in older I64 linkers.) If you're not on V8.3-1H1 with fairly recent UPDATE patches, get there. If you're on anything prior to V8.3, upgrade.

Make sure you're invoking the same image that you've installed, if you have the image installed. (Adding a version number onto an invocation will bypass the installed image processing, and you might be activating a different version of the image depending on how you've specified the invocation.)
H.Becker
Honored Contributor
Solution

Re: Error activating image ...

Hmm, I saw this report in another "forum" some time ago.

Essentially, at the time the image activator needs to relocate or fixup TPSHR, it finds an offset which is not in any image segment (or section if you prefer pre-I64 terminology) of the shareable images activated so far. This offset was read from the "dynamic table". Later, when reading the "dynamic table" the image activator encounters an illegal relocation type. So the image activator reports that something is wrong with or in the "dynamic table".

The dynamic table is part of the image file. It is usually read at activation time and brought into memory. If this "occurs very rarely", something else is going on. So this is very likely no problem in the image activator.

Running with different input parameters may obly be realated, if the image is activated via lib$fis. But that's not the case as you see the %DCL-W-ACTIMAGE.

Although these questions were already asked (and maybe answered in the mean time):
Is the image installed with /header? If it is, how?

As a workaround, I would try to install it /shared=addr. This may not be possible and/or may require more images to be installed that way.
P Muralidhar Kini
Honored Contributor

Re: Error activating image ...

Hi Klaus,

>> This is mystery to us, because the image DISPO_RETOUR runs with
>> different input parameters without any error messages
You mean to say that only when you pass a parameter of "SO_AUS_NN", you
are getting the "DCL-W-ACTIMAGE" messages. But with other input parameter
the program works fine.

What does the program do differently when provided with "SO_AUS_NN" as
the input parameter.

Regards,
Murali
Let There Be Rock - AC/DC
Hein van den Heuvel
Honored Contributor

Re: Error activating image ...

Hartmut>> The dynamic table is part of the image file. It is usually read at activation time and brought into memory.

That would be user writable memory right?


Klaus>> DISPO_RETOUR runs with different input parameters without any error messages.

My guess is that this input values cause some table/pointer to overflow and that a subsequent semi random happens to stomp on this table, setting that up for failure when it is (re)used.

This could be a tedious debug process, and yo may need process dumps.
Hmmm, of you could figure out how to find that table when you may be able to see a before and after image and spot what might have caused it.

It may be more productive to check that 'special value' to try to figure out what makes it special. Does it correspond with more 'objects'/'things'? fewer? zero? does it invoke object that have errors? along those lines...

fwiw,
Hein



H.Becker
Honored Contributor

Re: Error activating image ...

> That would be user writable memory right?

Not really: there is no "user code" running at that time. This is at activation time, no command line input was processed, yet.

Hein van den Heuvel
Honored Contributor

Re: Error activating image ...

Hein> That would be user writable memory right?
Hartmutt> Not really: there is no "user code" running at that time. This is at activation time, no command line input was processed, yet.

Right, but I had thought that the table would be used later on as well, but if it is only used for/during the fixups? Maybe LIB$FIS goes back to it? Dunno right now.

Klaus, is TPSHR linked with the images, or are the functions in TPSHR activated through LIB$FIND_IMAGE_SYMBOL?

fwiw,
Hein

H.Becker
Honored Contributor

Re: Error activating image ...

>Right, but I had thought that the table would be used later on as well, but if it is only used for/during the fixups? Maybe LIB$FIS goes back to it? Dunno right now.

Nope. The dynamic table or dynamic segment is only for the image activator. This segemnt is generated at link time. There is nothing in any object pointing to it. Nobody else knows where it is. (In case the image is not installed /header, the image activator deletes this process section after it is done with it.)

In my point of view, the DCL message excludes lib$fis, here.

Klaus Heim
Advisor

Re: Error activating image ...

Hoff>System is running V8.3-1H1. The latest patches had not been installed. The image/shared library is not installed. We use a foreign command, so we use activate the same image.

H.Becker>The errors are very rarely - but in the night. So we got an emergency call.
What is lib$fis?
The image and the shared library is not installed.
What do you mean with "install it /share=addr"? Install the image "DISPO_RETOUR" or install the shared library TPSHR?

P Muralidhar Kini>No. The problem is not the parameter.

Hein>TPSHR is linked and not activated through LIB$FIND_IMAGE_SYMBOL.

@All>The problem is not only with the shared library TPSHR. There are two other shared libraries SHR.EXE and $TASHR.EXE with the same problem. We had also 5 diffrent batch jobs with this problem. All jobs are similar. They define for each image an foreign command and do there work (call the different images with or without an parameter). The image DISPO_RETOUR is called many times - ex. first with SO_AUS parameter, second with SO_OV_RUS and third SO_AUS_NN and so on. The same image DISPO_RETOUR is activated many times (in one batch job) n times the activation is good - but the next activation goes wrong. The image and the shared library are the same. Nobody does any changes at 1:00 or 2:00 in the night. When the problem occurs we "just" start the batch job and anything is ok. In reality it is not "just" starting - first we must do some "undo" work - but we do no changes at the image or the shared library.

We had no problem on Alpha. We just "compile and link" ported our system. Is there any hint in building shared libraries on IA64?
Hoff
Honored Contributor

Re: Error activating image ...

Hoff>System is running V8.3-1H1. The latest patches had not been installed. The image/shared library is not installed. We use a foreign command, so we use activate the same image.

H.Becker>The errors are very rarely - but in the night. So we got an emergency call.
>What is lib$fis?

shorthand for lib$find_image_symbol. Also often used to refer to the dynld stuff (dlopen, etc) in the C RTL, which is based on the same mechanisms.

>The image and the shared library is not installed.
>What do you mean with "install it /share=addr"? Install the image "DISPO_RETOUR" or install the shared library TPSHR?

If it's not installed, then you can ignore the INSTALL command options here including /SHARE=ADDR

It can be inferred from the file names that different languages might be in play. Is the code using different VMS language settings or locales or different C settings in the different environments?

I'd suggest ringing up HP support. They'll probably want the most recent UPDATE kits and such loaded, of course.

And definitely check for marginal quotas, and other differences in the run-time environments; logical names and quotas can cause weird errors, and the C run-time environment is a forest of subtlety. And batch processes and interactive environments can also have quota differences.

The BADIMGOFF stuff was classically exec images; I don't know if that stuff has changed. (Hartmut would.) Are these images execlets or privileged? (The help here points to the potential use of the LOAD_SYS_IMAGES system parameter for cases of BADIMGOFF code involving Alpha. Might be stale help text, too; this is OpenVMS Alpha V8.3 text I'm looking at.)