Re: (select-window nil) crash with gcc-8.2.0

[Madhu]

* Eli Zaretskii <address@hidden> :
Wrote on Sun, 07 Apr 2019 06:50:11 +0300:

> On April 7, 2019 5:11:57 AM GMT+03:00, Madhu <address@hidden> wrote:
>> Hello, Compiling emacs with gcc-8.2.0 on amd64 with CFLAGS = -O2 -Os
>> causes emacs to crash when invoking M-: (select-window nil).  Clearly
>> gcc-8.2.0 is miscompiling code with these optimization settings (-O2
>> -Os) and I'm seeing crashes elsewhere where I am unable to isolate
>> the problem.  However the emacs crash is easily isolatable and could
>> point to the bug in either gcc, (or possibly in emacs if there is
>> some wrong assumption). Maybe someone with gcc-8.2.0 can verify the
>> crash?
>
> Please state the version of Emacs in which this happened, and
> preferably also show a backtrace from the crash that identifies the
> problematic variables on the C level.

[ First some pdmp notes:
I'd blown off the build directory and overwritten the installed version
but I had a copy of the binary dist. But I could not unpack the binary to
some other location and run emacs from there:
EMACSLOADPATH=/dev/shm/emacs-tmp/usr/share/emacs/27.0.50/lisp 
EMACSDATA=/dev/shm/emacs-tmp/usr/share/emacs/27.0.50/etc 
/dev/shm/emacs-tmp/usr/bin/emacs-27-vcs -Q
emacs: could not load dump file
"/usr/libexec/emacs/27.0.50/x86_64-pc-linux-gnu/emacs.pdmp": not built
for this Emacs executable.
I tried moving the installed pdmp to the bin directory where the
executable was unpacked, and then tried running it.

That was not enough either. emacs was still looking for
"/usr/libexec/emacs/27.0.50/x86_64-pc-linux-gnu/emacs.pdmp".

I tried to remove the pdmp file from the standard location

Now emacs started up but apparently it didn't pick up the pdmp file from
bin/. It loaded up loadup.el instead.

Then I realised that the bin dist was stripped, and a rebuild was only
 a few minutes.]

The following backtrace is from 051533c6 (03-apr-2019) on master on
 (select-window nil)

the problem is that if gcc is producing the wrong code then the
backtrace is unreliable.  This is not the backtrace one would expect
from calling (select-window nil).  But at least with this test case in
emacs I'm able to get *something* instead of 100s of empty nonsense
frames.

Attaching to process 6940
[New LWP 6941]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f1bad3bd76b in __pselect (nfds=7, readfds=0x7ffd3c33e4b0,
    writefds=0x7ffd3c33e530, exceptfds=0x0, timeout=<optimized out>,
    sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
69      ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
(gdb) c
Continuing.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x0000000000454ebf in select_window (window=0x0, norecord=0x0,
    inhibit_point_swap=<optimized out>) at lisp.h:1079
1079      return make_lisp_symbol (&lispsym[index]);
(gdb) back
#0  0x0000000000454ebf in select_window (window=0x0, norecord=0x0,
    inhibit_point_swap=<optimized out>) at lisp.h:1079
#1  0x0000000000501a40 in eval_sub (address@hidden) at lisp.h:2119
#2  0x0000000000502c03 in Feval (form=0xb9eb63, lexical=0x0) at eval.c:2117
#3  0x0000000000501117 in funcall_subr (address@hidden <Seval>,
    address@hidden, address@hidden) at eval.c:2907
#4  0x000000000050006d in Ffuncall (nargs=3, address@hidden)
    at lisp.h:2119
#5  0x0000000000526e3d in exec_byte_code (bytestr=<optimized out>,
    vector=<optimized out>, maxdepth=0x2a, args_template=<optimized out>,
    address@hidden, args=<optimized out>, address@hidden)
    at bytecode.c:633
#6  0x0000000000501d1d in funcall_lambda (address@hidden,
    address@hidden, arg_vector=0x9, address@hidden)
    at lisp.h:1862
#7  0x00000000005000d0 in Ffuncall (address@hidden,
    address@hidden) at eval.c:2844
#8  0x00000000004fdb3a in Ffuncall_interactively (nargs=5,
    args=0x7ffd3c33efe8) at callint.c:253
#9  0x0000000000501117 in funcall_subr (
    address@hidden <Sfuncall_interactively>,
    address@hidden, address@hidden) at eval.c:2907
#10 0x000000000050006d in Ffuncall (address@hidden, args=0x7ffd3c33efe0)
    at lisp.h:2119
#11 0x000000000050039b in Fapply (address@hidden,
    address@hidden) at eval.c:2450
#12 0x00000000004fdf63 in Fcall_interactively (function=0x7f1baaf3e480,
    record_flag=0x0, keys=0x7f1babcc742d) at lisp.h:1079
#13 0x000000000050112a in funcall_subr (
    address@hidden <Scall_interactively>, address@hidden,
    address@hidden) at eval.c:2910
#14 0x000000000050006d in Ffuncall (nargs=4, address@hidden)
    at lisp.h:2119
#15 0x0000000000526e3d in exec_byte_code (bytestr=<optimized out>,
    vector=<optimized out>, maxdepth=0x36, args_template=<optimized out>,
    address@hidden, args=<optimized out>, address@hidden)
    at bytecode.c:633
#16 0x0000000000501d1d in funcall_lambda (address@hidden,
    address@hidden, arg_vector=0x5, address@hidden)
    at lisp.h:1862
#17 0x00000000005000d0 in Ffuncall (address@hidden,
    address@hidden) at eval.c:2844
#18 0x00000000005001b6 in call1 (address@hidden, arg1=<optimized out>)
    at eval.c:2681
#19 0x00000000004b488a in command_loop_1 () at lisp.h:1079
#20 0x00000000004ff7a5 in internal_condition_case (
    address@hidden <command_loop_1>,
    address@hidden, address@hidden <cmd_error>)
    at eval.c:1352
#21 0x00000000004aa968 in command_loop_2 (address@hidden)
    at lisp.h:1079
#22 0x00000000004ff723 in internal_catch (address@hidden,
    address@hidden <command_loop_2>, address@hidden)
    at eval.c:1115
#23 0x00000000004aa917 in command_loop () at lisp.h:1079
#24 0x00000000004acabf in recursive_edit_1 () at keyboard.c:714
#25 0x00000000004accfb in Frecursive_edit () at keyboard.c:786
#26 0x0000000000414c67 in main (argc=2, argv=0x7ffd3c33f878) at emacs.c:1958
(gdb)