SIGUSR1 signal hung a Progress session - Forum - OpenEdge RDBMS - Progress Community

SIGUSR1 signal hung a Progress session

 Forum

SIGUSR1 signal hung a Progress session

This question is answered

Progress V11.7.5 on Linux

DBA sent the SIGUSR1 signal to a Progress session. Session created a protrace file but it was filled only partially: ABL Stack Trace section was empty. Session still held a handle to the protrace file. SIGUSER1 was added to a mask of signals being blocked (SigBlk). SIGCONT was moved from the caught signal mask (SigCgt) to the ignored signal mask (SigIgn). This also means that the session did not complete the creation of the protrace file.

strace shown:
14:34:16.785169 futex(0x7fe847541760, FUTEX_WAIT_PRIVATE, 2, NULL

Session has ignored SIGTERM and SIGINT and finally it was killed by SIGKILL.

How to debug such cases if they will happen again?

Regards,
George

Verified Answer
  • you might be able to attach with a debugger and get a process stack trace that way.

All Replies
  • you might be able to attach with a debugger and get a process stack trace that way.

  • Thanks, Gus. Do you mean this?:

    gdb -p $PID
    (gdb) where
    (gdb) quit
  • I'd use detach as well prior the quit as I've seen on some systems that it would kill off the PID.

  • With introduction of the -usernotifytime a Progress session can consist of two threads. Does it have a sense to debug both threads?

    By the way, it would be nice to have an article with basic guidelines of debugging on Unix level. :-)

    I played with dbg and strace and somehow hung a Progress session.

  • > On Aug 30, 2019, at 8:28 AM, George Potemkin wrote:

    >

    > Thanks, Gus. Do you mean this?:

    >

    >

    yes, and what Libor said.

  • > On Aug 30, 2019, at 9:57 AM, George Potemkin wrote:

    >

    > With introduction of the -usernotifytime a Progress session can consist of two threads. Does it have a sense to debug both threads?

    >

    >

    before that, on windoze, which hasn't got signals, there were two threads anyway. one was checking for database disconnect. the other was the main thread.=