Path: csiph.com!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!not-for-mail
From: Andrei Vagin <avagin@virtuozzo.com>
Newsgroups: gnu.bash.bug
Subject: Re: [PATCH] A terminating signal has to complete a bash process
Date: Fri, 4 May 2018 10:13:11 -0700
Lines: 100
Approved: bug-bash@gnu.org
Message-ID: <mailman.13403.1525454011.27995.bug-bash@gnu.org>
References: <20180430220520.32312-1-avagin@openvz.org> <e131b7b7-bd73-85b0-c5e4-88b66cab861a@case.edu> <20180501164422.GA7043@outlook.office365.com> <759a8efe-1c0a-2966-a2ae-59fc734fdad3@case.edu> <20180501235553.GA4218@outlook.office365.com> <6eb002a4-5cbc-1955-e3bd-f1eed5c2fd20@case.edu>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Cc: Andrei Vagin <avagin@openvz.org>, bug-bash@gnu.org
To: Chet Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <6eb002a4-5cbc-1955-e3bd-f1eed5c2fd20@case.edu>
User-Agent: Mutt/1.9.3 (2018-01-21)
Received-SPF: None (protection.outlook.com: virtuozzo.com does not designate permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2018 17:13:20.8703 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c4925983-1efc-4e71-e5bf-08d5b1e256a6
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3256
X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy]
X-Received-From: 104.47.2.127
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.21
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:14090

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/