1748089 Members
5149 Online
108758 Solutions
New Discussion юеВ

OpenVMS stack traceback

 
SOLVED
Go to solution
Max_Jarvis
Occasional Advisor

OpenVMS stack traceback

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.

8 REPLIES 8
H.Becker
Honored Contributor

Re: OpenVMS stack traceback

>>> (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.
Max_Jarvis
Occasional Advisor

Re: OpenVMS stack traceback

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...

Volker Halle
Honored Contributor

Re: OpenVMS stack traceback

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.

Max_Jarvis
Occasional Advisor

Re: OpenVMS stack traceback

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

Re: OpenVMS stack traceback

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.

Hoff
Honored Contributor
Solution

Re: OpenVMS stack traceback

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.)

H.Becker
Honored Contributor

Re: OpenVMS stack traceback

>>> 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.
Max_Jarvis
Occasional Advisor

Re: OpenVMS stack traceback

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.