Skip to main content
Question

(Unidata 8.2.2 on RHEL 7.9) Is there a way to connect the debugger to a phantom program?

  • July 31, 2023
  • 3 replies
  • 0 views
Kevin King

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?

    3 replies

    M
    • Marcus Rhodes
    • Participating Frequently
    • July 31, 2023

    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?

    Kevin King
    • Kevin King
    • Author
    • Participating Frequently
    • July 31, 2023

    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.

    Jonathan Smith
    Forum|alt.badge.img+4

    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,

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement