topic Re: Access violation when running a detached process in Operating System - OpenVMS

Access violation when running a detached process

A.W.R — Thu, 20 Mar 2008 14:08:49 GMT

Hi,

We have various programs that we run as detached processes. The programs are written in C.

We are now migrating to OpenVMS v8.3-1H1 on HP Integrity with C v7.3-18.

On the Alpha we start them without the DCL environment.

On the Integrity when we start the detached processes without the DCL environment, we get an access violation and the program terminates. The dump file is attached.

If we start them with in the DCL environment using LOGINOUT.EXE the process runs correctly.

Any input on what maybe causing this would be greatly appreciated.

Thanks
Andrew

Re: Access violation when running a detached process

Jess Goodman — Thu, 20 Mar 2008 14:26:47 GMT

I would guess that this a bug in the code that, through good luck, did not cause a problem on the Alpha, but is biting you in the a** on Integrity. :)

In your program you apparently call the C routine PUTENV. This takes a string argument. Is the CHAR array for that string defined as STATIC? If not you could get an access violation later (after the routine that calls PUTENV exits).

Re: Access violation when running a detached process

Volker Halle — Thu, 20 Mar 2008 14:45:00 GMT

Andy,

consider to create a process dump (use $ RUN/DET/DUMP) and try to figure out what's happening from the dump.

Look at your code (probably DBCMCU) and try to figure out what it's doing. If you think everything is o.k., consider to hand the dump to either Oracle or HP ;-)

The code may just assume that a CLI is available, although I can't see something like this to directly happen in putenv or get_environ_offset. But these routines will traverse virtual memory in the process, which could have been corrupted.

Volker.

Re: Access violation when running a detached process

Hoff — Thu, 20 Mar 2008 14:46:24 GMT

In addition to the process dump, you can also use the debugger and troubleshoot it directly. (Yes, you can use the debugger on a detached process. it takes a little set-up work, but...) While this approach might perturb the run-time environment (if there's a heap corruption or stray pointer), it can be a familiar environment and faster than digging through dumps.

If you have DECwindows around, SET DISPLAY or such to create a WSA device, and pass this in as SYS$INPUT, SYS$OUTPUT and SYS$ERROR on the $creprc call, or on the RUN /DETACH.

(There's a "back-door" in LOGINOUT here, too, where passing a WSA device as SYS$ERROR sets up DECW$DISPLAY for you.)

You can also use DBG$INPUT and DBG$OUTPUT logical names (in a logical name table visible to the detached process) and aim those logical names at an unallocated terminal. (In the absence of an unallocated serial terminal, I've used CREATE /TERMINAL or the underlying X calls DwtDECtermPort or DECW$CREATE_DECTERM to create a DECterm terminal using DECwindows, and to then pass that in via these logical names.)

A common error that can arise here involves process quotas or PQL minimum system parameter settings, as the memory quotas need to be circa 2x to 3x of those of Alpha.

Here, I see slzsetevar is calling putenv, and putenv is tipping over. This could be a calling error, or it could also be a heap corruption. (putenv is commonly used, and tends not to have errors, so this is probably either an error in the calling code, or some sort of a run-time corruption that is tripping putenv.)

Coincidently, I posted up some information on debugging an access violation (ACCVIO) signal just yesterday:

http://64.223.189.234/node/800

Stephen Hoffman
HoffmanLabs LLC

Re: Access violation when running a detached process

Hoff — Thu, 20 Mar 2008 14:53:46 GMT

BTW, putenv is documented as calling malloc, and if the heap is stuffed up, the putenv code will often tip over...

I'll assume you are not trying to create a symbol or logical name here, as lib$set_symbol and lib$set_logical would be better choices. And the former expects a CLI around.

Some tips on debugging C code weirdness, and an intro to heap errors (and pointers to tools):

http://64.223.189.234/node/401