%SYSTEM-F-ACCVIO Macro SNALU62 runtime-error

[Phillip Tusa]

Greetings to all!

We are attempting to migrate to the I64 rx-2620 OpenVMS 8.2-1 from VAX 4000-700a using SNA LU 6.2 and HP assembler Macro Language.

When we try to run the application on I64 we get the following error message at run-time:

%SYSTEM-F-ACCVIO, access violation ...
%TRACE-F-TRACKBACK, symbolic stack dump follow

image module routine line
AUS_SNA1
SNALU62SH COMPLETE_VERB SNALU62$$SCHEDULE_ATTACH_POST


AUS_SNA1
PTHREAD$RTL THD_THREAD thBase
PTHREAD$RTL THD_INIT pthread_main

%TRACE-I_END, end of trace stack dump


We are pretty much at the "end of our rope" with this run-time error.

Any assistance would be appreciated, thanks!

Phil

[John Reagan · Accepted solution]

The format of your posted traceback is hard to read. Is the ACCVIO in your code or inside the SNA product? What is at the PC in question?

When you said "Macro Language", you mean Macro-32 correct? Perhaps you are using a Macro-32 feature that does not port to I64 (or Alpha). Have you read the Macro Compiler Porting and User Manual?

[Volker Halle]

Phil,

SNALU62SH seems to be a shared library and part of the SNA APPC LU6.2 programming interface software. If your application program crashes in this routine, you have either provided bad parameters and they are not being correctly checked by the called routine or there is a bug in the HP SNA LU6.2 software.

Consider to create a process dump:

$ SET PROC/DUMP
$ run your-application

This will create an imagename.DMP file in the current default directory. You can look at that process dump with:

$ ANAL/PROC/IMAGE=your-application-image imagename.DMP
DBG> SHOW CALL
DBG> EXA/INS @PC
DBG> EXIT

Then post the output returned from the above commands as an attached .TXT file.

Consider to raise a call with HP, if HP software crashes with an ACCVIO !

Volker.

[Hoff]

Ok, you have Macro32 VAX assembler code that is now being processed by the Macro32 compiler on OpenVMS, and is encountering a run-time ACCVIO error. That error is pretty common. The ACCVIO itself tells you exactly what instruction failed, and what was transpiring during the failure.

It's quite possible that a latent bug in Macro32 application code could surface during the port, or a bug could be unintentionally inserted during the port, or this could be a bug in pthread, C or other run-time library, or in the LU62 product. Or an error within the lower reaches of OpenVMS.

Since the source code to the Macro32 code is available, compile it with debugging enabled, and walk through the communications code up to the failure. Debug the ACCVIO as far as you can. Alternatively, you can use knowledge of the code and the failure to set a breakpoint closer to the trigger -- that can be found based on something up the traceback that you recognize, or can be found using lib$output "breadcrumb" messages or such -- and navigate more quickly to the area of the failure.

Once in the neighborhood of the failure -- and this involves looking at the arguments passed into function calls in the area of the failing call in detail, heap usage, register usage, etc -- and verify the context of the environment. From this, you can find the bug in the application code, or you can provide a reproducer to HP that will speed the resolution, or that might lead you (or HP) to a workaround pending resolution.

[John Gillings]

Phil,
Please post the complete and exact ACCVIO and traceback messages. There's a lot of information in there. Understanding what all the numbers mean is the key to debugging this type of error.

[Phillip Tusa]

Hello again to all ...

I have attached the error message log file that is being generated at run-time by the image process aus_sna1.exe


Any assistance would be appreciated, thanks!

Phil

[Volker Halle]

Phil,

after reformatting the output in the attached .TXT files, things are getting a little bit clearer:

It looks like that routine SNALU62$$SCHEDULE_ATTACH_POST in module COMPLETE_VERB in shareable image SNALU62SH is calling back into your main image, which then fails with an ACCVIO at PC=00025980, trying to access VA=00000052

Please compile your AUS_SNA1 main module with /DEBUG/LIS/MACHINE and re-execute the test. And link with /MAP. Consider to issue a SET PROC/DUMP before running AUS_SNA1.EXE

You would then probably get a line number and routine name reported for the AUS_SNA1 image in the traceback data.

Volker.

[Robert Brooks_1]

We are pretty much at the "end of our rope" with this run-time error.

--

What's the response from your local HP support centre?

I'm taking a wild stab that there's a problem in the DECthreads library, as supplied by HP.

If so, you'll need to formally report the problem to receive a fix.

-- Rob

[Volker Halle]

Rob,

the traceback data in the attached .TXT file needs some re-formatting, before you can 'see' the problem more clearly ;-(

The failing PC is in the user's main image, so that absolves the SNALU62SH image - at least for now.

Volker.

[Phillip Tusa]

The problem has been resolved!

There was nothing wrong with the SNA APP LU 6.2
library. Instead we found a Macro-32 assembler call that was in error in syntax and a logic error, too.

Thanks to all who assisted!

Phil