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

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

 
SOLVED
Go to solution
Art Wiens
Respected Contributor

VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

This isn't my problem to solve (I am not the programmer), but I wanted to get get some insight if possible ...

Environment:
- ES47 model 4, 8GB memory
- VMS v7.2-2 restored from an existing Alpha 800, 512MB memory
- Upgraded to v7.3-2, all VMS patches applied

I tried one of the applications (written in BASIC v1.3 and uses FMS v2.4 screens). I am able to launch the app and navigate it's menues, choose a function that I have a bit of familiarity with and inquire/retrieve a record ... all seems to work fine. Trying to exit the application (Gold PF1) the process gets an ACCVIO (see attached).

Is there anything that can be gleaned from this little bit of info? Is there anything I can do/try from a VMS perspective? I don't have access to the source code to answer any such specific questions.

Cheers,
Art
19 REPLIES 19
Hein van den Heuvel
Honored Contributor
Solution

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

It is not unlikely to be a badly handled error.

Those addresses do not mean much ot anyone.
The very least you need to provide/consider is some crude memory map.
And I would also run once with $SET WATCH FILE/CLA=MAJOR. It is not unlikely to be an environment / file problem

$SET PROC/NAM=TEST
$SET WATCH FILE/CLA=MAJOR
$RUN program
:
! manoeuver around, untill just before exit
! Watch for errors in set watch output all along

^Y SPAWN ! Or second window

$ANAL/SYSTEM
SDA> SET PROC TEST
SDA> SHOW PROC/CHAN
SDA> SHOW PROC/IMAGE
SDA> EXAM/INSTR interesting-address-from-accvio - 40 ; 80

Does SDA in 7.3-2 have LNM TRACE?
Again, just in case it is environmental and the access happens to try a logical name use that.

LNM LOAD
LNM START TRACE

Back to main window and try the exit.

LNM STOP TRACE
LNM SHOW TRACE (filter for the right PID)

Good luck!
Hein.






DECxchange
Regular Advisor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Hello,
I doubt if something like this has anything to do with your OS upgrade. It is probably an application level bug. So there's no way you can recompile and relink that particular program with debug?

$ basic/debug/noopt
$ link/deb /opt

If there is an option file? This may not be the exact syntax for recompiling and relinking on your system, just a general suggestion.

Otherwise, I think those SDA suggestions are very informative and useful. I think though at some point, you want to be able to get access to source code or somebody who does have access to source code and solve the problem that way.

Another thought, you might want to check the process quotas, if they changed with the upgrade. Do you have a copy of the operating system before the upgrade you can fall back on to see if you still get this error? And you can check for any changes in quotas?
Hoff
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

This ACCVIO looks comparatively trivial to find, given access to the source code and a debug build.

On zero evidence, my first target would be for an error in a declared exit handler ($dclexh), or something in the main exit path. But again, a reproducible error is a wonderful thing.

And no, it's not clear if this a bug introduced in the upgrade, or a latent bug in the application. My bet would be on the latter.
Volker Halle
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Art,

issue a SET PROC/DUMP and then run your program. Once it will ACCVIO, you'll get a process dump written. Consider the run with CMKRNL priv set, so that you get all of of the process address space and important parts of system address space dumps.

$ ANAL/PROC imagename.DMP
DBG>

You can now debug the failing isntruction, you can invoke SDA (from the DBG> prompt type SDA) to look at the images activated in the process and the channels and have all the information you need - except direct mapping of adresses to source code lines.

Volker.
Ian Miller.
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

would not running with CMEXEC be enough as system data structures are often protected ERKW
____________________
Purely Personal Opinion
Volker Halle
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Ian,

you're right. Running the image (creating the process dump) with CMEXEC prevents the following error message:

%SDA-W-EXCLDATA, data excluded from dump due to insufficient privilege

when trying to analyze the process dump with SDA.

Merry Christmas,

Volker.
Art Wiens
Respected Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

So I was just about to try some of your suggestions and voila ... the problem is gone!(?) I did nothing to it over the weekend, noone else knows the system is up yet. I went back to make sure I was using the right account ... yes. Tried with and without privs, no diff. How can this be?! Self healing applications?!

What I've found is that the problem only occurs if "the user" is an RTA device ie. a Decnet session (SET HOST 0) which is what I was doing on Friday. If I Telnet in, it works fine. Something changed in Decnet IV in VMS 7.3-2?

I will continue the investigation.

Cheers,
Art
Art Wiens
Respected Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Using the SET WATCH FILE command and side by side comparing a Telnet vs Decnet session: at the point where it should give a message saying "Exiting the xxx application", on the Decnet session there is an extra file access then the error:

%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Access SORTMSG.EXE;1 (2232,3,0) Status: 00000001
%XQP, Thread #0, Control function (2232,3,0) Status: 00000001
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0009, PC=0000000000EE3298, PS=0000001B

The Telnet session does not access this file - other than that, all other accesses are the same.

Art
Hoff
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

This smells like a sensitivity to whatever cruft happens to be left sitting on the stack, or similar.

Exit and error handlers are sensitive to these sorts of subtleties, and ASTs can encounter similar sensitivities.

Errors that move are errors that involve uninitialized values, or stack values, or race conditions, unsynchronized completions or other such.