I have this phantom program that runs for a bit and then just stops functioning. The program continues to run, but doesn't do what it's supposed to do and does not respond to any control inputs other than a Linux kill. Seems to be caught in some kind of a dead loop. There are no READU locks preventing the program from running, it just ... doesn't do anything after it's been running for a while.
Is there any way to connect the Unidata debugger to the phantom to evaluate variables or step through the program?
Does it exhibit the same behavior when running in the foreground?
I have this phantom program that runs for a bit and then just stops functioning. The program continues to run, but doesn't do what it's supposed to do and does not respond to any control inputs other than a Linux kill. Seems to be caught in some kind of a dead loop. There are no READU locks preventing the program from running, it just ... doesn't do anything after it's been running for a while.
Is there any way to connect the Unidata debugger to the phantom to evaluate variables or step through the program?
While the program can run in the foreground, the problem seems to start after it's been running overnight. I'm remote, so I wouldn't be able to keep a network connection that long without the risk of being disconnected. I did put some debugging code (writing out to files, CRT status messages) in there to hopefully catch it falling down, but I thought it would be so handy to be able to debug it remotely. However, it appears that the remote debugging feature in Unidata is designed for a completely different use case.
I have this phantom program that runs for a bit and then just stops functioning. The program continues to run, but doesn't do what it's supposed to do and does not respond to any control inputs other than a Linux kill. Seems to be caught in some kind of a dead loop. There are no READU locks preventing the program from running, it just ... doesn't do anything after it's been running for a while.
Is there any way to connect the Unidata debugger to the phantom to evaluate variables or step through the program?
Kevin,
Previously I've used the TANDEM approach to debug a phantom process. It seems the phantom process is ignoring the SIGINT request when attempting to enter view mode. I will have to investigate this further as I suspect this may be a bug and is an area where similar problems have seen problems before. If I used a hardcoded DEBUG condition it did allow me to use the debugger via TANDEM.
I used this program first of all
CRT @(-1)
FOR A = 1 TO 500
CRT "BEFORE SLEEP 5 (":A:")"
SLEEP 5
CRT "AFTER SLEEP 5 (":A:")"
NEXT A
END
Testing TANDEM when the process you attach to is a foreground program you see the SIGINT is responded to and you enter the debugger.
:TANDEM 2
AFTER SLEEP 5 (2)
BEFORE SLEEP 5 (3)
AFTER SLEEP 5 (3)
BEFORE SLEEP 5 (4)
Entering FEED_MODE
AFTER SLEEP 5 (4)
BEFORE SLEEP 5 (5)
Sending SIGINT to process id 7124
***DEBUGGER called at line 5 of program BP_KK.PH.TEST
!END
::
:
Running the program as a phantom you will see the SIGINT request is ignored, this i think is a bug
:TANDEM 4
AFTER SLEEP 5 (2)
BEFORE SLEEP 5 (3)
AFTER SLEEP 5 (3)
BEFORE SLEEP 5 (4)
Entering FEED_MODE
AFTER SLEEP 5 (4)
BEFORE SLEEP 5 (5)
Sending SIGINT to process id 7126
AFTER SLEEP 5 (5)
BEFORE SLEEP 5 (6)
I then used the following program, ran as phantom and attached to it via TANDEM and you'll see the DEBUG works.
I understand this is not ideal but it may allow you to utilize this.
CRT @(-1)
FOR A = 1 TO 500
IF A = 8 THEN DEBUG
CRT "BEFORE SLEEP 5 (":A:")"
SLEEP 5
CRT "AFTER SLEEP 5 (":A:")"
NEXT A
END
:TANDEM 4
AFTER SLEEP 5 (5)
BEFORE SLEEP 5 (6)
Entering FEED_MODE
Sending SIGINT to process id 7129
AFTER SLEEP 5 (6)
BEFORE SLEEP 5 (7)
AFTER SLEEP 5 (7)
***DEBUGGER called at line 3 of program BP_KK.PH.TEST
!END
Remember to compile with the -D option
If this does not work for you there is one final thing you could try but I do not want to muddy the waters (so to speak) on this discussion.
Regards,
