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
you might be able to attach with a debugger and get a process stack trace that way.
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.=