From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: Re: (select-window nil) crash with gcc-8.2.0 Date: Sun, 07 Apr 2019 10:49:10 +0530 Message-ID: References: <0993F546-D21B-4722-8300-7A9CDDCE7EB8@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="29711"; mail-complaints-to="usenet@blaine.gmane.org" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 07 07:22:10 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hD0Ft-0007ZR-Kp for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 07:22:09 +0200 Original-Received: from localhost ([127.0.0.1]:34617 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hD0Fp-0003ZA-L7 for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 01:22:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hD0FF-0003Z2-Om for emacs-devel@gnu.org; Sun, 07 Apr 2019 01:21:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hD0FE-0007Uj-Dg for emacs-devel@gnu.org; Sun, 07 Apr 2019 01:21:29 -0400 Original-Received: from [59.93.21.75] (port=55086 helo=localhost.localdomain) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hD0FD-0007RK-LK for emacs-devel@gnu.org; Sun, 07 Apr 2019 01:21:28 -0400 Original-Received: (qmail 24124 invoked by uid 500); 7 Apr 2019 05:19:10 -0000 In-Reply-To: <0993F546-D21B-4722-8300-7A9CDDCE7EB8@gnu.org> (Eli Zaretskii's message of "Sun, 07 Apr 2019 06:50:11 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 59.93.21.75 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235058 Archived-At: * 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 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=, sigmask=) 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=) 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=) 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 , 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=, vector=, maxdepth=0x2a, args_template=, nargs=nargs@entry=4, args=, 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 , 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 , 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=, vector=, maxdepth=0x36, args_template=, nargs=nargs@entry=1, args=, 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=) at eval.c:2681 #19 0x00000000004b488a in command_loop_1 () at lisp.h:1079 #20 0x00000000004ff7a5 in internal_condition_case ( bfun=bfun@entry=0x4b441d , handlers=handlers@entry=0x4f50, hfun=hfun@entry=0x4acd85 ) 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 , 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)