[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGINT handling
From: |
Stephane Chazelas |
Subject: |
Re: SIGINT handling |
Date: |
Sun, 20 Sep 2015 17:12:45 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
[...]
> 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.
[...]
Sorry, please disregard that.
I thought the termsig_handler was being invoked upon SIGINT as
the SIGINT handler, but it is being called explicitely by
set_job_status_and_cleanup so the problem is elsewhere.
child_caught_sigint is 0 while if I understand correctly it
should be 1 for a cmd that calls exit() upon SIGINT. So that's
probably probably where we should be looking.
--
Stephane
- Re: SIGINT handling, (continued)
- Re: SIGINT handling, Chet Ramey, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Chet Ramey, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
Re: SIGINT handling, Chet Ramey, 2015/09/19
- Re: SIGINT handling, Stephane Chazelas, 2015/09/19
- Re: SIGINT handling, Chet Ramey, 2015/09/19
- Re: SIGINT handling, Stephane Chazelas, 2015/09/20
- Re: SIGINT handling,
Stephane Chazelas <=
- Re: SIGINT handling, Stephane Chazelas, 2015/09/20
- Re: SIGINT handling, Chet Ramey, 2015/09/21
- Re: SIGINT handling, Stephane Chazelas, 2015/09/21
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Greg Wooledge, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Bob Proulx, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
Re: SIGINT handling, Chet Ramey, 2015/09/24