Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Traceback of a detached process

Traceback of a detached process

How can I get a traceback of a crashing detached subprocess? It is launched via SYS$CREPRC from a detached process that launched via LOGINOUT (i.e. it has a CLI).
15 REPLIES
RBrown_1
Trusted Contributor

Re: Traceback of a detached process

Assuming you built the crashing image with traceback, I would have thought that the traceback would have appeared in the subprocess's SYS$ERROR. If you did not specify the ERROR parameter in your call to $CREPRC, then perhaps it goes to SYS$OUTPUT of the parent process.

But just a wild guess.

Re: Traceback of a detached process

The parent's sys$output and sys$error files don't contain any traces.

While the subprocess is running, it holds a file open called [defaultdir].;N But at rundown, the file seems to disappear.

VMS 7.3-2 Alpha, btw.

Re: Traceback of a detached process

And yes, it is not built with /NOTRACEBACK. (Default /TRACEBACK is implied.)

John Gillings
Honored Contributor

Re: Traceback of a detached process

Elli,

Sounds suspiciously like the process hasn't been given sufficient quotas to send the output to a file. What does your PQL look like? Note this is a very tricky parameter to get right, and often critically important.

Maybe it would be best to post your whole $CREPRC call for the parent, and the code which starts the subprocess.

At the very least you should have the final status in the accounting log.
A crucible of informative mistakes
Ian Miller.
Honored Contributor

Re: Traceback of a detached process

You may also wish to enable process dump for that process
____________________
Purely Personal Opinion

Re: Traceback of a detached process

One interesting error shows up in the SYS$OUTPUT file:

Error activating command interpreter SYS$SYTEM:DCL
Process quota exceeded

Now to figure out which PQL?

Re: Traceback of a detached process

I've turned on SET PROC/DUMP for all subprocesses and await their expected demises. All our processes declare exit handlers. However, the exit handlers do not resignal. Does that mean the dumps will not report a traceback?
Andy Bustamante
Honored Contributor

Re: Traceback of a detached process

Another option is to use Availability Manager to monitor quotas and focus in on which quota is the issue.

Availability Manager also allows for on the fly changes to quotas.

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Ian Miller.
Honored Contributor

Re: Traceback of a detached process

Availability Manager is a good tool for looking at process quota issues.

Do you specify quotas in the $CREPRC or use the default values from the PQL_ parameters?
____________________
Purely Personal Opinion
John Gillings
Honored Contributor

Re: Traceback of a detached process

Elli,

Unless you specify a PQL in your CREPRC call, you will get system defaults and minima (see SYSGEN parameters PQL_Dxxx and PQL_Mxxx).

My general rule is to always specify a complete PQL with "reasonable" values, as the defaults are usually too low to do anything useful.

Be careful with alignment when defining your PQL, it's a very poorly designed structure and very easy to get wrong.

Your error indicates PRCLM.
A crucible of informative mistakes

Re: Traceback of a detached process

@Ian: The former. We don't supply PQLs in the $CREPRC call.
Hoff
Honored Contributor

Re: Traceback of a detached process

>We don't supply PQLs in the $CREPRC call.

But you're adding that into your code, because that omission could otherwise lead to odd and server-specific and potentially transient instabilities within the code, right?

Some debugging-related topics:

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

Worst-practices:

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

Defensive Coding Practices:

http://h71000.www7.hp.com/wizard/wiz_1661.html

Re: Traceback of a detached process

Unfortunately, right now - (lots of history here) - I am debugging crashes of legacy code that I've inherited. Pragmatically, I must work around the problems at this time by setting environment variables, but at the same time I recognize that supplying PQLs at CREPRC call time is preferable.

The symptoms are that this code has been migrated from V7.2-1/UCX 5.1 to a V7.3-2/UCX 5.4 ECO 7 environment. Crashes are abundant now. As far as we can tell, all SYSGEN and SYSUAF environment quotas are identical. Memory configurations are similar.
Hoff
Honored Contributor

Re: Traceback of a detached process

The crashes are quite possibly arising because the code is broken in any of various ways. Failing to have a PQL specification is a good one, and spot on for detached-process errors. These sorts of weird bugs and race conditions and synchronization errors and quota problems are fairly typical of coding errors; bad code can leave you chasing bugs all over the place.

You're in a no-win right now. Talk to your boss. That'll help this case move toward resolution, whether that's fixes to help solidify the code, or no changes here (quite possibly in preparation for a migration, or as a prerequisite part of the justification of some managerial expenditure), or dusting off and updating your skills and your resume and performing a self-migration.
John Gillings
Honored Contributor

Re: Traceback of a detached process

Elli,

If you really can't change the code, your only option is to adjust SYSGEN PQL parameters to give your processes sufficient quota. This is NOT a good solution, as it will potentially affect other, completely unrelated processes on your system. It can be a useful thing to do on a test system as proof of concent and to determine appropriate values for the various quotas. Once you know what they should be, restore SYSGEN values, and update the source.
A crucible of informative mistakes