topic Re: Traceback of a detached process in Operating System - OpenVMS

Traceback of a detached process

Elli M Barasch — Thu, 16 Sep 2010 19:41:57 GMT

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

Re: Traceback of a detached process

RBrown_1 — Thu, 16 Sep 2010 19:59:07 GMT

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

Elli M Barasch — Thu, 16 Sep 2010 20:06:16 GMT

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

Elli M Barasch — Thu, 16 Sep 2010 20:07:47 GMT

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

Re: Traceback of a detached process

John Gillings — Thu, 16 Sep 2010 20:44:48 GMT

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.

Re: Traceback of a detached process

Ian Miller. — Fri, 17 Sep 2010 12:21:05 GMT

You may also wish to enable process dump for that process

Re: Traceback of a detached process

Elli M Barasch — Fri, 17 Sep 2010 12:26:23 GMT

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

Elli M Barasch — Fri, 17 Sep 2010 13:01:57 GMT

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?

Re: Traceback of a detached process

Andy Bustamante — Fri, 17 Sep 2010 15:05:23 GMT

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.

Re: Traceback of a detached process

Ian Miller. — Fri, 17 Sep 2010 15:06:07 GMT

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?

Re: Traceback of a detached process

John Gillings — Sun, 19 Sep 2010 21:28:31 GMT

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.

Re: Traceback of a detached process

Elli M Barasch — Mon, 20 Sep 2010 16:34:02 GMT

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

Re: Traceback of a detached process

Hoff — Mon, 20 Sep 2010 18:08:10 GMT

>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

Elli M Barasch — Mon, 20 Sep 2010 18:16:03 GMT

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.

Re: Traceback of a detached process

Hoff — Mon, 20 Sep 2010 18:56:03 GMT

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.

Re: Traceback of a detached process

John Gillings — Mon, 20 Sep 2010 21:13:57 GMT

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.