pthread_sigmask and gdb

pthread_sigmask and gdb

[Jaimon Jose]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

I have a server program where the main thread block on all signals and
handle them appropriately.  This was required for a graceful shutdown
(using SIGINT ) or a reconfigure ( HUP ). However, I see that, gdb
doesn't allow me to break into the debugger ( interrupt the running
program ) if I block SIGINT.  The "info signal" states that,
Signal        Stop      Print   Pass to program Description

SIGHUP        Yes       Yes     Yes             Hangup
SIGINT        Yes       Yes     No              Interrupt

Still, SIGINT is passed to the program being debugged instead of GDB
handling this.  I have attached a sample program where I can reproduce
this. I tried this on Solaris and HPUX.  Once I attach to the running
program, I can interrupt the program using "Ctrl-C".  But, this doesn't
work on gdb ( on SLES, SuSE 10.1 and RHAS 3.0 - gdb 6.4 and 6.0 ) and
the signal is delivered to the running program.  Any help is appreciated.

--jaimon

[-- Attachment #2: signal_test.cpp --]
[-- Type: text/plain, Size: 1163 bytes --]


#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <string.h>


int main(void)
{
	int err = 0;
	bool bShutdown = 0;
	sigset_t set, old;

	sigfillset(&set);
	sigdelset(&set,SIGTRAP);
//	sigdelset(&set, SIGINT );

	//
	//	Needed by gdb
	// 
	sigdelset(&set, SIGUSR1 );
	sigdelset(&set, SIGUSR2 );
	sigdelset(&set, SIGUNUSED );

   /* Java VM uses these signals in Linux */
   for(int s=SIGRTMIN; s <= SIGRTMAX - 4; s++)
		sigdelset(&set,s);

	if (pthread_sigmask(SIG_BLOCK, &set, 0) != 0)
		fprintf(stderr, "pthread_sigprocmask failed: %s\n", strerror(errno)); 

	//
	// Start additional threads
	//

	while (bShutdown == false)
	{ 
		int sig = 0; 
		siginfo_t info;

		if ((sig = sigwaitinfo(&set, &info)) == -1)
		{
			fprintf(stderr, "Received invalid signal -1.\n");
			continue;
		}

		switch (sig)
		{
			case SIGINT:
				fprintf(stderr, "Received SIGINT\n"); 
				// fall through
			case SIGTERM:
				fprintf(stderr, "Got SIGINT/SIGTERM signal, shutting down\n"); 
				bShutdown = true;
				break;
			default:
				fprintf(stderr, "Ignoring the unexpected signal, %d\n", sig);
				break;
		}
	}
	//
	// Do additional cleanup
	//
	return 0;
}

Re: pthread_sigmask and gdb

[Andreas Schwab]

Jaimon Jose <jjaimon@Yahoo.com> writes:

> Still, SIGINT is passed to the program being debugged instead of GDB
> handling this.  I have attached a sample program where I can reproduce
> this. I tried this on Solaris and HPUX.  Once I attach to the running
> program, I can interrupt the program using "Ctrl-C".  But, this doesn't
> work on gdb ( on SLES, SuSE 10.1 and RHAS 3.0 - gdb 6.4 and 6.0 ) and
> the signal is delivered to the running program.  Any help is appreciated.

Looks like a kernel bug.  Since gdb does not receive any notification of
the signal it cannot do anything about that.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pthread_sigmask and gdb

[Daniel Jacobowitz]

On Mon, Nov 06, 2006 at 03:04:46PM +0100, Andreas Schwab wrote:
> Jaimon Jose <jjaimon@Yahoo.com> writes:
> 
> > Still, SIGINT is passed to the program being debugged instead of GDB
> > handling this.  I have attached a sample program where I can reproduce
> > this. I tried this on Solaris and HPUX.  Once I attach to the running
> > program, I can interrupt the program using "Ctrl-C".  But, this doesn't
> > work on gdb ( on SLES, SuSE 10.1 and RHAS 3.0 - gdb 6.4 and 6.0 ) and
> > the signal is delivered to the running program.  Any help is appreciated.
> 
> Looks like a kernel bug.  Since gdb does not receive any notification of
> the signal it cannot do anything about that.

Yes.  To be more specific, the problem is not pthread_sigmask but
sigwaitinfo / rt_sigsuspend.  I thought some recent kernel changes
(TIF_RESTORE_SIGMASK) would have improved this, and in fact I can't see
how it still happens, but it does still seem to happen.

-- 
Daniel Jacobowitz
CodeSourcery

Re: pthread_sigmask and gdb

[Jaimon Jose]

Andreas Schwab wrote the following on 11/06/2006 07:34 PM:
> Looks like a kernel bug.  Since gdb does not receive any notification of
> the signal it cannot do anything about that.
My assumption was that gdb blocks on all signals and delivers to the
application being debugged based on the signal mask set in the gdb. 
I have tested this on 2.4.21 and 2.6.16.  Its hard to believe this was
never caught.


Thanks
--jaimon

Re: pthread_sigmask and gdb

[Daniel Jacobowitz]

On Mon, Nov 06, 2006 at 07:47:50PM +0530, Jaimon Jose wrote:
> 
> 
> Andreas Schwab wrote the following on 11/06/2006 07:34 PM:
> > Looks like a kernel bug.  Since gdb does not receive any notification of
> > the signal it cannot do anything about that.
> My assumption was that gdb blocks on all signals and delivers to the
> application being debugged based on the signal mask set in the gdb. 
> I have tested this on 2.4.21 and 2.6.16.  Its hard to believe this was
> never caught.

Sigwaitinfo is a very special case of signal delivery.

-- 
Daniel Jacobowitz
CodeSourcery