From: Madhu <enometh@meer.net>
To: emacs-devel@gnu.org
Subject: Re: (select-window nil) crash with gcc-8.2.0
Date: Sun, 07 Apr 2019 10:49:10 +0530 [thread overview]
Message-ID: <m37ec6xui9.fsf@leonis4.robolove.meer.net> (raw)
In-Reply-To: <0993F546-D21B-4722-8300-7A9CDDCE7EB8@gnu.org> (Eli Zaretskii's message of "Sun, 07 Apr 2019 06:50:11 +0300")
* Eli Zaretskii <0993F546-D21B-4722-8300-7A9CDDCE7EB8@gnu.org> :
Wrote on Sun, 07 Apr 2019 06:50:11 +0300:
> On April 7, 2019 5:11:57 AM GMT+03:00, Madhu <enometh@meer.net> 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 (form=form@entry=0xb9eb63) at lisp.h:2119
#2 0x0000000000502c03 in Feval (form=0xb9eb63, lexical=0x0) at eval.c:2117
#3 0x0000000000501117 in funcall_subr (subr=subr@entry=0x90f5c0 <Seval>,
numargs=numargs@entry=2, args=args@entry=0x7ffd3c33ed30) at eval.c:2907
#4 0x000000000050006d in Ffuncall (nargs=3, args=args@entry=0x7ffd3c33ed28)
at lisp.h:2119
#5 0x0000000000526e3d in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=0x2a, args_template=<optimized out>,
nargs=nargs@entry=4, args=<optimized out>, args@entry=0x9)
at bytecode.c:633
#6 0x0000000000501d1d in funcall_lambda (fun=fun@entry=0x7f1bab8c2f95,
nargs=nargs@entry=4, arg_vector=0x9, arg_vector@entry=0x7ffd3c33eff0)
at lisp.h:1862
#7 0x00000000005000d0 in Ffuncall (nargs=nargs@entry=5,
args=args@entry=0x7ffd3c33efe8) at eval.c:2844
#8 0x00000000004fdb3a in Ffuncall_interactively (nargs=5,
args=0x7ffd3c33efe8) at callint.c:253
#9 0x0000000000501117 in funcall_subr (
subr=subr@entry=0x90f100 <Sfuncall_interactively>,
numargs=numargs@entry=5, args=args@entry=0x7ffd3c33efe8) at eval.c:2907
#10 0x000000000050006d in Ffuncall (nargs=nargs@entry=6, args=0x7ffd3c33efe0)
at lisp.h:2119
#11 0x000000000050039b in Fapply (nargs=nargs@entry=3,
args=args@entry=0x7ffd3c33f138) 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 (
subr=subr@entry=0x90f0c0 <Scall_interactively>, numargs=numargs@entry=3,
args=args@entry=0x7ffd3c33f280) at eval.c:2910
#14 0x000000000050006d in Ffuncall (nargs=4, args=args@entry=0x7ffd3c33f278)
at lisp.h:2119
#15 0x0000000000526e3d in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=0x36, args_template=<optimized out>,
nargs=nargs@entry=1, args=<optimized out>, args@entry=0x5)
at bytecode.c:633
#16 0x0000000000501d1d in funcall_lambda (fun=fun@entry=0x7f1bab85b30d,
nargs=nargs@entry=1, arg_vector=0x5, arg_vector@entry=0x7ffd3c33f498)
at lisp.h:1862
#17 0x00000000005000d0 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7ffd3c33f490) at eval.c:2844
#18 0x00000000005001b6 in call1 (fn=fn@entry=0x3bd0, arg1=<optimized out>)
at eval.c:2681
#19 0x00000000004b488a in command_loop_1 () at lisp.h:1079
#20 0x00000000004ff7a5 in internal_condition_case (
bfun=bfun@entry=0x4b441d <command_loop_1>,
handlers=handlers@entry=0x4f50, hfun=hfun@entry=0x4acd85 <cmd_error>)
at eval.c:1352
#21 0x00000000004aa968 in command_loop_2 (ignore=ignore@entry=0x0)
at lisp.h:1079
#22 0x00000000004ff723 in internal_catch (tag=tag@entry=0xc7b0,
func=func@entry=0x4aa953 <command_loop_2>, arg=arg@entry=0x0)
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)
next prev parent reply other threads:[~2019-04-07 5:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-07 2:11 (select-window nil) crash with gcc-8.2.0 Madhu
2019-04-07 3:50 ` Eli Zaretskii
2019-04-07 5:19 ` Madhu [this message]
2019-04-07 7:13 ` Andreas Schwab
2019-04-07 16:16 ` Eli Zaretskii
2019-04-07 18:33 ` Paul Eggert
2019-04-07 18:38 ` Eli Zaretskii
2019-04-07 18:42 ` Paul Eggert
2019-04-08 22:08 ` Richard Stallman
2019-04-09 4:39 ` Paul Eggert
2019-04-09 23:13 ` Richard Stallman
2019-04-10 2:01 ` Paul Eggert
2019-04-11 18:38 ` Paul Eggert
2019-05-26 6:51 ` finding the pdmp file again Madhu
2019-05-27 10:32 ` Andreas Schwab
2019-05-27 20:13 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m37ec6xui9.fsf@leonis4.robolove.meer.net \
--to=enometh@meer.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.