CXXLINK error --- %SYSTEM-F-ACCVIO, access Violation, reason mask

[Arch_Muthiah]

All,

I am trying to build C and C++ sources using MAKE utility (by Todd and Ned) on Alpha PWS 600/OpenVMS 7.3-2.
Using both Compaq C V6.5-001 and Compaq C++ V6.5-004.

The same cc, cxx, cxxlink are working fine to build all other modules except this module. No problem with make utility, but I receive the following "%SYSTEM-F-ACCVIO..." errors, tried many times; contacted HP, they suggested me to remove /nouser and axp.opt/option from the cxxlink cmnd and then asked me to use system's LINK command, but I receive the same error.

The compile cmnd and error details are atatched.

Compilation is successful, but I receive this
%SYSTEM-F-ACCVIO error all the time.
I do this from SYSTEM account, increased the pgflquo to 400000, BYTLM=99,000, ENQLM=4000 and the sysgen parameter CLISYMTBL=500, 500 (current, default); gblpages=8400,8400; gblpagfil=1024,1024; gblsections = 2,2

Your suggestions will be very usefull.

Thanks
Archie

[Arch_Muthiah]

btw, the axp.opt file contains only a line "sys$library:libcxxstd.olb/lib"

Thanks
Archie

[Hoff]

If you've not already done so, you might want to get back on the phone with HP support, working toward a resolution.

An upgrade is one approach, and certainly ensure the current ECO kits are loaded for OpenVMS Alpha V7.3-2.

From the HP web site: "The CXXLINK utility defines the logical names LNK$LIBRARY[_n] to reference the SYS$LIBRARY:LIBCXXSTD.OLB library." Which means you should not need nor want to reference it, unless you're doing something odd with the command. The CXXLINK command is itself a front-end on the standard LINKER. (The /NOUSER stuff affects this same area, so I'm guessing there's something that HP is looking at here.)

Has the OpenVMS Alpha V7.3-2 box been patched to current? Any LINKER, UPDATE and any other pieces.

The stackdump implies a corrupt register or a corrupt stack. A zero in a pointer somewhere.

Are there any warnings that might be derailing the operations? /NOWARNING can be useful, or it can mask real problems.

And you'll want to get back on the phone with HP support.

[John Gillings]

Archunan,

No OpenVMS command should ever terminate with an improperly handled condition. This is, by definition, a bug. Quotas shouldn't enter into it - if that were the problem, the program should have terminated cleanly with a clear EXQUOTA type message, identifying the low quota.

Please raise a case against your service contract and request (or, if they don't cooperate, DEMAND!) that the case be elevated to engineering.

Be prepared to provide a complete reproducer - ideally a single, self contained command procedure that will create all necessary files and issue all necessary commands to reproduce the fault. Make sure you test it on at least one other system to ensure you don't have any unexpected environmental dependencies.

[Hein van den Heuvel · Accepted solution]

As John indicates, an ACCVIO is never acceptable.

Does the error happen quickly or after a long time?

I'm just wondering whether it is the real linker doing that, or a helper behind cxxlink (not knowing what cclink does).

I'm more concerned with the /NOREPLACE switch than the /NOUSER switch as I do not believe the /[no]REPLACE switch is often used?

Personally I would try to help HP support by checking out which files were touched last when the ACCVIO occurs. To do so, use SET WATCH FILE/CLASS=MAJOR (required CMKRNL).
Switch of when done using SET WATCH FILE/CLASS=NONE


Note: The link command refers to "libfin"
and "libfinc" twice. Either somethign very smart is attempted (in which case a comment would be appropriate) or it's just stu*#$!

How complex is the defintion og finc_lib: ?
It's usage is carried forward, so it rally only needs to be specified once, until changed. By specifying is multiple time you may well EXPONENTIALLY grow the number of places the linker/rms tries to look for libraries. Simplify and try again?!
Along the same lines, try with the option RMS_RELATED_CONTEXT=no in the .opt file.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Hein van den Heuvel]

Dunno why I thought the procedure used /NOREPLACE.
Sorry for that confusion.
I suspect I was confused due to the /REPO switch (cxx repository).

And sorry 'bout the typos in general.

Anyway, the first focus should be to determine whether the accvio is happening in the LINK itself or the cxx pre-processing.

Cheers,
Hein.

[Arch_Muthiah]

Hoff/John/Hein,

Thanks for your time going through my posting and your responses.

Hoff: I have latest patch VMS732_UPDATE-V1200 applied. Thanks for the info on libcxxstrd.olb/lib inside the option file.

John: I contacted HP by phone and send the details, they responded immly with the suggestions I mentioned.

Hein: I got confused after seeing your response with /[no]REPLACE...

And tried your suggestions. finc_lib is just the process level logical point to one of the local directory. libfin, libfinc, libfinv are different OLBs on that directory.

No problem with compilation. Access violation error comes within 5 secs. I just packaged the executable (with access violation issue) in the application for testing purpose. when I run that particular executable, it gave the main program (register.cpp) name which actually fails in cxxlink with "access violation" during linking and the module name (is an another register.cpp included in finc_lib:libfinc.olb). I have attached the error.

Actually these are TCPIP client server programs communicates to windows based application using socket and qio routines.
For this type of program, do we need add any special keys in cxxlink. I tried LINK command also.

Thanks
Archunan

[Volker Halle]

Archunan,

$ CXXLINK/LOG shows at least the actual command which fails with the accvio and

$ ANAL/SELECT=IDENT SYS$SYSTEM:*LINK

is probably useful to determine the versions.

Volker (just the messenger).

[Arch_Muthiah]

Volker,

Linker details are
CXX$LINK.EXE --> CXX V6.5-004
LINK.EXE --> A13-02

I found the cxxlink log file, it does not indicates any specific command which causes this access violation, but provides missing *.obj files, this files should be of course available in the cxx_rep directory (mangling), but I searched it does not have those *.obj files; also the compilation does not report any issue.

But the log file finally assembled the LINK command which is equivalent to CXXLINK command and it has new option file which has all the *.obj files in cxx_rep directory.

But yesterday evening I found that the my CXXLINK command fails even for a small test program, looks like my linker corrupted or any other reason. I applied the latest latest patches.

John:
If I send the reproducer (save set already created) to HP, they will take lots of time, thatswhy I am expecting any other suggestions from you all.


Thanks
Archunan

[Robert Brooks_1]

If I send the reproducer (save set already created) to HP, they will take lots of time, thats why I am expecting any other suggestions from you all.

----

Note that you're doing this on an unsupported version of the operating system. V7.3-2 went off "standard" support at the end of 2006; only those folks paying for prior version support are likely to get a timely response to a problem that may have been already fixed on a supported version (which would be V8.2 and newer)

If the linker is the cause of the access violation, there's likely little that you can do to correct our mistake.

-- Rob