Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: SIGINT handling
Date: Wed, 23 Sep 2015 21:52:41 -0400
Organization: ITS, Case Western Reserve University
Lines: 48
Approved: bug-bash@gnu.org
Message-ID: <mailman.1694.1443059568.19560.bug-bash@gnu.org>
References: <20150918151439.GA16455@chaz.gmail.com> <55FDC8B4.4000505@case.edu> <20150919213101.GA4393@chaz.gmail.com> <55FE0BB8.8040500@case.edu> <20150920155219.GA8614@chaz.gmail.com>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: usenet.stanford.edu 1443059569 13142 208.118.235.17 (24 Sep 2015 01:52:49 GMT)
X-Complaints-To: action@cs.stanford.edu
Cc: bug-bash <bug-bash@gnu.org>, chet.ramey@case.edu
To: Stephane Chazelas <stephane.chazelas@gmail.com>
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <20150920155219.GA8614@chaz.gmail.com>
X-Junkmail-Whitelist: YES (by domain whitelist at mpv2.tis.cwru.edu)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]
X-Received-From: 129.22.105.37
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref: csiph.com gnu.bash.bug:11552

On 9/20/15 11:52 AM, Stephane Chazelas wrote:

> When the above code exits without printing "hi", we see this
> call stack for instance (breakpoint on kill() in gdb):
> 
> #0  kill () at ../sysdeps/unix/syscall-template.S:81
> #1  0x000000000045dd8e in termsig_handler (sig=<optimized out>) at sig.c:588
> #2  0x000000000045ddef in termsig_handler (sig=<optimized out>) at sig.c:554
> #3  0x00000000004466bb in set_job_status_and_cleanup (job=0) at jobs.c:3539
> #4  waitchld (block=block@entry=1, wpid=20802) at jobs.c:3316
> #5  0x000000000044733b in wait_for (pid=20802) at jobs.c:2485
> #6  0x0000000000437992 in execute_command_internal (command=command@entry=0x70aa48, asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1,
>     fds_to_close=fds_to_close@entry=0x70bb68) at execute_cmd.c:829
> #7  0x0000000000437b0e in execute_command (command=0x70aa48) at execute_cmd.c:390
> #8  0x0000000000435f23 in execute_connection (fds_to_close=0x70bb48, pipe_out=-1, pipe_in=-1, asynchronous=0, command=0x70bb08) at execute_cmd.c:2494
> #9  execute_command_internal (command=0x70bb08, asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1, fds_to_close=fds_to_close@entry=0x70bb48)
>     at execute_cmd.c:945
> #10 0x000000000047955b in parse_and_execute (string=<optimized out>, from_file=from_file@entry=0x4b5f96 "-c", flags=flags@entry=4) at evalstring.c:387
> #11 0x00000000004205d7 in run_one_command (command=<optimized out>) at shell.c:1348
> #12 0x000000000041f524 in main (argc=3, argv=0x7fffffffe198, env=0x7fffffffe1b8) at shell.c:695
> 
> That is, SIGINT is being handled *after* the SIGINT handler has
> been restored to its default of exiting the shell.

An alternate explanation is that somehow the shell is forgetting that
SIGINT is trapped.  I don't see how or why that would happen, but I
don't have enough information to determine whether that's the case.

> Now, I'm not sure how to best fix that as I suppose we don't get
> any guarantee of when SIGINT will be delivered (it may be why
> ksh93 ignores SIGINT altogether and relies solely on
> WIFSIGNALED)
> 
> The above scenario suggests SIGCHLD is being delivered before
> SIGINT which is strange. I'd expect SIGINT to be inserted by the
> kernel in both cmd and bash queues upon CTRL-C, and the SIGCHLD
> would necesarily come after those SIGINT. Could it be that
> SIGCHLD jumps the queue?

The above scenario doesn't suggest that SIGCHLD is being delivered at
all.  The shell is doing a blocking waitpid for a specific pid.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/