Re: es signal handling bug on recent Linuces

[Paul Haahr <haahr@jivetech.com>]

I wrote:
> I don't think it's a problem with es's internal state, but rather with
> how it sets the signal handling bits for the process.  [...]

After a little bit of testing, useless exploration with strace, and a
profitable visit to /proc, it appears that, when the SIGINT signal
handler is called, SIGINT is blocked.  If memory serves (and it may not;
es was the last real Unix code I've written), that's the way things are
supposed to be.  But, when the signal handler exits, either by return or
longjmp, the signal is supposed to be unblocked.

That unblocking was not occurring.  (I wonder if it has to do with the
longjmp.)

I've appended some code to this message which appears to cure the bug
when the appropriate compile-time flag is set, though es still sometimes
reports ``wait: No child processes'' when processes are interrupted.  No
idea what that happens.

Any suggestions are welcome.

Needs to be packaged better, of course.


Scott wrote:
> To add fuel to your fire: Folks around here using bash2 have noticed
> that keyboard signals sometimes behave strangely under RH2.6.

Can you say more about the symptoms?

--p

/* catcher -- catch (and defer) a signal from the kernel */
static void catcher(int sig) {
#if SYSV_SIGNALS /* only do this for unreliable signals */
	signal(sig, catcher);
#endif
	if (hasforked)
		/* exit unconditionally on a signal in a child process */
		exit(1);
	if (caught[sig] == 0) {
		caught[sig] = TRUE;
		++sigcount;
	}
	interrupted = TRUE;

#if DUMB_ASS_LINUX_BUG
	{
		sigset_t unblock;
		sigemptyset(&unblock);
		sigaddset(&unblock, sig);
		sigprocmask(SIG_UNBLOCK, &unblock, NULL);
	}
#endif
	
	if (slow)
		longjmp(slowlabel, 1);
}