SIGUSR1 signal hung a Progress session

Posted by George Potemkin on 30-Aug-2019 09:07

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

Posted by gus bjorklund on 30-Aug-2019 11:40

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

All Replies

Posted by gus bjorklund on 30-Aug-2019 11:40

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

Posted by George Potemkin on 30-Aug-2019 12:26

Thanks, Gus. Do you mean this?:

gdb -p $PID
(gdb) where
(gdb) quit
Posted by Libor Laubacher on 30-Aug-2019 13:18

I'd use detach as well prior the quit as I've seen on some systems that it would kill off the PID.

Posted by George Potemkin on 30-Aug-2019 13:55

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.

Posted by gus bjorklund on 30-Aug-2019 18:56

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

>

> Thanks, Gus. Do you mean this?:

>

>

yes, and what Libor said.

Posted by gus bjorklund on 30-Aug-2019 18:58

> 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.=

This thread is closed