bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrei Vagin
Subject: Re: [PATCH] A terminating signal has to complete a bash process
Date: Fri, 4 May 2018 10:13:11 -0700
User-agent: Mutt/1.9.3 (2018-01-21)

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 (address@hidden <printf_builtin>, 
address@hidden, address@hidden, 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>, address@hidden, pipe_out=<optimized out>, address@hidden, address@hidden, 
    address@hidden) at execute_cmd.c:4330
#8  0x0000000000438b7c in execute_command_internal (address@hidden, 
address@hidden, address@hidden, address@hidden, 
    address@hidden) 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    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]