COBOL, C and C++ Memory Allocation Failure

[Wayne Byrd]

Memory allocation failure in C program on Alpha architecture.

Using COBOL program as main program, a C program and a C++ program are called (which also calls the C program). Development of calling interface is nearly completed with successful use of WEBSphere MQ. The C++ program makes heavy use of Apache DOM for creating XML.

STR$COPY_DX fails with access violation or produces unpredictable results other times when called from C program. Not using any special options with the CXXLINK command but suspect answer may be in this area.

Help! To borrow from the old Notes ID, I'm driving a 57 accvio.

[Hoff]

The usual trigger for a failure with STR$COPY_DX or other services is a coding error or a preceding heap corruption, though it's certainly feasible to blow out P0 process address space or process PGFLQUOTA if you're loading large enough wads of data.

Verify the validity of the descriptors being passed to the call using the debugger.

And verify that there have been no modifications to any dynamic descriptors.

Do some debugging, and try to reproduce the error in the debugger. And see what's going on with the arguments.

[Wayne Byrd]

The C program has worked successfully for decades (literally) and the problem started occurring after linking with the C++ object.

There is less than 1k of data being passed.

Of course I have been in the debugger for hours with this problem and have found replacing STR$COPY_DX with my own manual building and loading of the string descriptor is working but would like to understand why this is necessary because I am concerned this may be pointing to other issues not yet encountered.

Even though member alignment is turned off in C (it is turned off by default in COBOL), an EXAMINE/ASCID shows the correct string in C in the debugger but there is sometimes extra garbage at the end of the string when exmined in COBOL. The string is passed BY DESCRIPTOR in COBOL.

[Hoff]

You're going to get to resolve this locally, or post the source code or a reproducer (and hope somebody has the time to debug it for you), or call in somebody to debug the code and the behavior for you. Addressing these cases without access to the source code is difficult at best.

(You've described a whole lot of "moving parts" in this source code, too; some rather significant and complex pieces and parts. And some significant recent changes. More than enough to make even guessing difficult. And these errors can be obscure. That you have a specific call failing reliably is certainly very useful, though.)

There's clearly some sort of a heap or stack error here, or a descriptor mismatch. The descriptor you have referenced clearly has issues between the C and the COBOL environments.

FWIW: if you're working with a dynamic descriptor that's been allocated storage, the contents of that dynamic descriptor should not typically be written directly by application code; write access should only be via the RTL calls.

As for a path forward, look at the contents of the descriptor data structure that arrives, and at the Calling Standard manual, and at the COBOL requirements. Mixed language programming usually involves looking at these documents and at example code (eg: COBOL to COBOL) to see what a calling or called routine expects or uses.

That the code has worked for years without errors is certainly interesting, but that does not preclude the existence of latent errors. I'm aware of bugs two and three times the age of this code, and in commonly-used code. A 30+ year old bug surfaced in yacc, for instance.

For some C debugging information, start here:

http://labs.hoffmanlabs.com/node/401

Here's what an ACCVIO really means:

http://labs.hoffmanlabs.com/node/800

And an intro to OpenVMS features and mechanisms in C programs:

http://labs.hoffmanlabs.com/node/273

[Guy Peleg]

Wayne,

Much more information is needed to determine
the cause. As a start, post the register
dump from the ACCVIO and the MAP file
for the image.

Regards,

Guy Peleg
Maklee Engineering
http://www.maklee.com

[Volker Halle]

Wayne,

if the program terminates with an ACCVIO, consider to enable a process dump:

$ SET PROC/DUMP
$ RUN image...

This will - in the case of of an image exit due to an imprperly handled condition - save all of the process virtual address space in a process dumpefile (imagename.DMP) and allow you to later use ANAL/PROC to examine the static situation at the time of the ACCVIO.

Volker.

[Wayne Byrd]

I was using the dynamic instead of the static class when building the string descriptor in C++.

Thanks for the advice.