Re: [PATCH] A terminating signal has to complete a bash process

[Andrei Vagin]

On Thu, May 03, 2018 at 04:29:13PM -0400, Chet Ramey wrote:
> On 5/1/18 7:55 PM, Andrei Vagin wrote:
> 
> >> If it's not obvious, I'm trying to determine whether making this change
> >> will add any more value than simply exiting (perhaps with a particular
> >> exit status).
> > 
> > It will add more value. Without this changes, we will not know whether a
> > bach process crashed or exited. If it will not generate a core dump after
> > a crash, the tools like abrtd, coredumpd, etc will not detect this crash
> > and will not report about this abnormal behaviour.
> 
> OK, we'll try it. I'll be interested to see if any core dumps created by
> causing a SIGSEGV will overwrite any stack information from the `real'
> fatal signal.

We can easy try to check that a result core dump is functional. I did
the next experiment:

1. Add a bug in a code which handles printf

diff --git a/builtins/printf.def b/builtins/printf.def
index d39a6d3f..5cef6118 100644
--- a/builtins/printf.def
+++ b/builtins/printf.def
@@ -250,6 +250,7 @@ printf_builtin (list)
 
   vflag = 0;
 
+  *((long *) 0) = 5; \
   reset_internal_getopt ();
   while ((ch = internal_getopt (list, "v:")) != -1)
     {

Now when printf is called from a script, a process will be killed by
SEGV

2. Prepare a test enviroment
$ echo /tmp/core > /proc/sys/kernel/core_pattern
$ ulimit -c unlimited

$ cat init.sh 
#!/bin/bash

function finish {
  echo Exit trap
}
trap finish EXIT

printf hello

3. Run a test script in a new pid namespace

$ unshare -pfUr ./bash init.sh
Exit trap
Segmentation fault (core dumped)

4. Let's look what we can get from a core dump file

$ gdb -c /tmp/core.1 ./bash
(gdb) bt
#0  termsig_handler (sig=11) at sig.c:628
#1  0x0000000000462c01 in termsig_handler (sig=<optimized out>) at sig.c:484
#2  termsig_sighandler (sig=<optimized out>) at sig.c:540
#3  <signal handler called>
#4  printf_builtin (list=0xd9aa08) at ./printf.def:253
#5  0x000000000041fa65 in execute_builtin (builtin=builtin@entry=0x48d880 
<printf_builtin>, flags=flags@entry=0, subshell=subshell@entry=0, 
words=<optimized out>) at execute_cmd.c:4535
#6  0x0000000000420842 in execute_builtin_or_function (flags=<optimized out>, 
fds_to_close=0xd9be08, redirects=<optimized out>, var=0x0, builtin=0x48d880 
<printf_builtin>, words=0xd9aa28)
    at execute_cmd.c:5028
#7  execute_simple_command (simple_command=<optimized out>, pipe_in=<optimized 
out>, pipe_in@entry=-1, pipe_out=<optimized out>, pipe_out@entry=-1, 
async=async@entry=0, 
    fds_to_close=fds_to_close@entry=0xd9be08) at execute_cmd.c:4330
#8  0x0000000000438b7c in execute_command_internal 
(command=command@entry=0xda4108, asynchronous=asynchronous@entry=0, 
pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1, 
    fds_to_close=fds_to_close@entry=0xd9be08) at execute_cmd.c:807
#9  0x000000000043a4ae in execute_command (command=0xda4108) at 
execute_cmd.c:405
#10 0x00000000004249ec in reader_loop () at eval.c:180
#11 0x00000000004235ba in main (argc=2, argv=0x7ffe30cdfce8, 
env=0x7ffe30cdfd00) at shell.c:792
(gdb) frame 0
#0  termsig_handler (sig=11) at sig.c:628
628         *((volatile unsigned long *) NULL) = 0xdead0000 + sig;
(gdb) p sig
$1 = 11

(gdb) frame 4
#4  printf_builtin (list=0xd9aa08) at ./printf.def:253
253     *((long *) 0) = 5; \

In this case, the core dump file isn't corrupted, and it gives us all what we
need to investigate this bug.

Thanks,
Andrei

> 
> Thanks for the patch.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/