Debugger Question

[dschwarz]

We have recently upgraded a development system from OpenVMS 7.3 to 7.3-2 (patch level VMS732_UPDATE-V1400). One of our programmers has a problem with debugging a program in a subprocess spawned from another debug session.

small reproducer (fortran):

program testit
implicit none
integer*4 i
integer*4 j
i = 3
j = 4
end

program testit2
implicit none
integer*4 i
integer*4 j
i = 3
j = 4
end

fortr/debu/noop testit
fortr/debu/noop testit2
link/debu testit
link/debu testit2

run testit

dbg> step
dbg> spawn

$ run testit 2

Under OpenVMS 7.3 this works, I get the debugger version (OpenVMS Alpha Debug64 Version V7.2X-022) and the debug prompt.

Under openVMS 7.3-2 (debug version OpenVMS Alpha Debug64 Version V7.3-200) there is no prompt. Main session is HIB, dbg$xxxx and subprocess are in LEF.

It is not possible to patch the debugger because these patches introduce bugs concerning examine/deposit fortran record elements.

What has changed ?
Is there a workaround ?

[Hein van den Heuvel]

Did you try set the job logical DBG$PROCESS to
MULTIPROCESS ?


$ HELP/LIBRARY=SYS$HELP:DBG$HELP DEBUG Logical_Names DBG$PROCESS
:
" Use the multiprocess configuration to debug programs that normally run in more than one process."
:
For more information, see help on Debugging_Configurations.
:


hth,
Hein.

[dschwarz]

Hein,
until this moment I didn't try this. But now I tried this first:
$ HELP/LIBRARY=SYS$HELP:DBG$HELP DEBUG Logical_Names DBG$PROCESS


DEBUG

Logical_Names
Sorry, no documentation on DEBUG LOGICAL_NAMES DBG$PROCESS

I became curious and tried it with 8.3
Help ... did work
but the problem with the debugger persists. Even worse: I had to stop/id=nnn my session because ctl-Y didn't work.
It (ctl-Y) worked with 7.3-2.

[Hein van den Heuvel]

Oh well. Seemed like a good place to try this option.
Along the lines of "what problem are you really trying to solve", may we assume that the processesing to be tested must have a parent - subprocess relationship?
Can you work around that, punt the issue by performing the test simply using two debug sessions? That would seem a lot easier on th whole!

To figure out what is going on, you may need to check the status of the various processes involved, and notably what they are waiting for. ANAL/SYS ... SHOW PROC/CHAN ... look for 'busy' can be a handy way to see mailbox IO.
Maybe you are low on process resources? (bytlm, tqe,...).
Does $ SHOW PROC/CONT on 7.3-2 have the 'q' page?
Probably not... find a command file to list quotas and usage?
Something wrong with Pthreads?
Just guesses.

Good luck!
Hein.

[Hoff]

Can you create a small reproducer? HP will want to see that.

The alternative (and the approach I usually use) redirects the debugger session and debugger output from the detached processes (or your subprocess, here) to another terminal.

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

[dschwarz]

Hein,
the software to test has a parent-subprocess relationship. Testing the real programs in two different sessions would not be the same.

For my primitive reproducer there are three processes involved:
main process - state HIB
dbg$xxxx - state LEF
subprocess spawned from within the debugger - state LEF

None of the processes seems to have problems with quotas.
ANA/SYS -> SHO PROC/CHAN ... shows no busy i/o channel, again none of the processes involved has any busy i/o channel !!!

SHOW PROC does not have the q page on 7.3-2 but ana/sys ... SHOW PROC helps.
On 8.3 there are no problems with quota (q page available).

What do you try to tell me about PThreads ?
We don't use it explicitly.

Hoff,
my original post contains a small reproducer, nearly as simple as I can imagine.
I also tried to redirect debugger input and output (DBG$INPUT and DBG$OUTPUT) to another terminal, btw. that's the way I use to work, too. But it does not work. I also tried to redirect debug input/output to different terminals (one for the main process, the other one for the subprocess). Always the same result: debugging not possible.

[Hoff]

Yep, I see that reproducer now.

If forcing the single-process debugger or raising the debug session via DECwindows doesn't work, then you'll probably end up starting another session.

Looks like the debugger is getting itself tangled.

[dschwarz]

Hoff,
yes, that's what it looks like.
A new 'feature' introduced with 7.3-2
and updated with 8.3 to force user to kill their processes.