Traceback of a detached process

[Elli M Barasch]

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

[RBrown_1]

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.

[Elli M Barasch]

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.

[Elli M Barasch]

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

[John Gillings]

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.

[Ian Miller.]

You may also wish to enable process dump for that process

[Elli M Barasch]

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?

[Elli M Barasch]

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]

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.

[Ian Miller.]

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?

[John Gillings]

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.

[Elli M Barasch]

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

[Hoff]

>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

[Elli M Barasch]

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]

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]

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.