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 c...@case.edu http://tiswww.cwru.edu/~chet/
