topic Re: OpenVMS stack traceback in Operating System - OpenVMS

OpenVMS stack traceback

Max_Jarvis — Fri, 14 Oct 2011 10:02:37 GMT

I'm having a bit of trouble with the OpenVMS stack traceback facility (the facility whereby when a process crashes, sys$output contains a printout starting with %TRACE_F_TRACEBACK, showing an unwind of the stack). It appears that if the crashing process is a detached process, the traceback is produced only if 'set message /facility' was in force when the process was created. If I enter 'set message /nofacility' before creating the detached process, then when the detached process crashes, no traceback is produced. This doesn't seem to apply to non-detached processes. I haven't found any reference to this behaviour in the OpenVMS manuals. So, I have two questions:

(a) Have I totally got the wrong end of the stick here, or is this really true and it's supposed to be like this?

(b) Is there a way of doing 'set message /facility' using a system service? If so, my detached processes could do that immediately after they start up, to make sure there will be a traceback if they crash.

This is OpenVMS 8.3-1H1 running on an rx2660, using the HP C compiler version 7.1. The detached processes are created by a command file using loginout.exe, like this:

$ run sys$system:loginout.exe -
/detach -
/page_file=500000 -
/process_name=xyz -
/priority=nn -
/input=runxyz.com -
/output=xyz.out

'runxyz.com' looks like this:

$ define /table=lnm$process_directory lnm$temporary_mailbox lnm$group
$ run xyz.exe

Thanks in advance... Max.

Re: OpenVMS stack traceback

H.Becker — Fri, 14 Oct 2011 11:31:05 GMT

>>> (a) Have I totally got the wrong end of the stick here, or is this really true and it's supposed to be like this?

I can't reproduce this. What I get is a trace back which is started with "%F-TRACEBACK, symbolic stack dump follows". And that makes some sense.

>>> (b) Is there a way of doing 'set message /facility' using a system service? If so, my detached processes could do that immediately after they start up, to make sure there will be a traceback if they crash.

Can't you add a "$ set message/facility" to the runxyz.com?

What kind of problem do you have, ACCVIO, QUOTA, ... ? The traceback code is (image/merge) activated when it is needed. If you have a resource problem in the detached process, it may not be possible to load and/or execute that code.

Re: OpenVMS stack traceback

Max_Jarvis — Fri, 14 Oct 2011 12:21:25 GMT

Yes, I've already tried putting 'set message /facility' in runxyz.com, and that does fix the problem. Thanks.

I've been playing round with it a bit more and it seems that for a detached process, setting any one of the message parameters /facility, /text, /identification and /severity ensures you get a traceback on a crash. But if all four of them are off, you get no traceback. This looks as if it could be deliberate, but doesn't seem to be mentioned in the manuals.

I've noticed that Eli M Barasch posted a similar problem (lack of traceback when detached processes crash) in September 2010, and nobody seems to have mentioned 'set message' in their reply. Maybe this was his problem too?

As for my crashes: I don't have any crashes to worry about at the moment. This is about ensuring that I will get a traceback if crashes occur in the future. I'm testing with a deliberate ACCVIO crash caused by this code in a detached process:

char *p = "JJJ";

*p = 0;

Thanks for the help...

Re: OpenVMS stack traceback

Volker Halle — Fri, 14 Oct 2011 12:27:13 GMT

Max,

by default, all the message parameters are enabled, aren't they ? Why not in your process ? Do you have some login procedure, which turns them off ?

Volker.

Re: OpenVMS stack traceback

Max_Jarvis — Fri, 14 Oct 2011 12:33:26 GMT

Yes, I have turned off these message parameters to stop the flood of unwanted messages such as 'PID of created process is 1234'.

Re: OpenVMS stack traceback

Volker Halle — Fri, 14 Oct 2011 12:37:59 GMT

Max,

that may explain, why Hartmut couldn't reproduce your problem...

This may therefore be a behaviour triggered by an unusual local system configuration.

Volker.

Re: OpenVMS stack traceback

Hoff — Fri, 14 Oct 2011 12:40:35 GMT

Add the /DUMP qualifier to the RUN command (for non-LOGINOUT processes) and add the /DUMP switch onto the individual image invocations when started at DCL), and catch your errors using the process dump mechanisms and the OpenVMS debugger. (qv: ANALYZE /PROCESS_DUMP, etc)

Or better, add your own signal handler and your own process-dump handing code into the application, and log the stuff that matters to your application, should it tip over.

(Not sure where a reply I'd thought was posted here went, either.)

Re: OpenVMS stack traceback

H.Becker — Fri, 14 Oct 2011 12:54:30 GMT

>>> But if all four of them are off, you get no traceback. This looks as if it could be deliberate, but doesn't seem to be mentioned in the manuals.

This may be caused by the implementation. Traceback output may be written with $putmsg (or an action routine called from $putmsg). And if there is nothing to format, nothing will be shown. This is the same in interactive and detached processes.

For analyzing process dump files, you may want to have debug symbols in a DSF. Have a look at the linker manual.

Re: OpenVMS stack traceback

Max_Jarvis — Fri, 14 Oct 2011 16:22:19 GMT

Yes, I think you may be right. In any case I now know enough to do what I need... thanks to all for your help... Max.