From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38748: 28.0.50; crash on MacOS 10.15.2 Date: Thu, 02 Jan 2020 16:06:23 +0200 Message-ID: <834kxej6lc.fsf@gnu.org> References: <20191226130420.GB71460@breton.holly.idiocy.org> <83fth7qa3a.fsf@gnu.org> <83blrtq2j0.fsf@gnu.org> <83sgl3lyii.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="189184"; mail-complaints-to="usenet@blaine.gmane.org" Cc: alan@idiocy.org, jguenther@gmail.com, 38748@debbugs.gnu.org To: Andrii Kolomoiets Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 02 15:07:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1in183-000mzu-UA for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2020 15:07:12 +0100 Original-Received: from localhost ([::1]:41400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in182-0005ou-CW for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2020 09:07:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33524) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in17v-0005om-MP for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2020 09:07:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1in17u-0005HO-Jd for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2020 09:07:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60646) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1in17u-0005HE-G6 for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2020 09:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1in17u-0005iF-AD for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2020 09:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2020 14:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38748 X-GNU-PR-Package: emacs Original-Received: via spool by 38748-submit@debbugs.gnu.org id=B38748.157797399221915 (code B ref 38748); Thu, 02 Jan 2020 14:07:02 +0000 Original-Received: (at 38748) by debbugs.gnu.org; 2 Jan 2020 14:06:32 +0000 Original-Received: from localhost ([127.0.0.1]:38386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1in17Q-0005hO-Gs for submit@debbugs.gnu.org; Thu, 02 Jan 2020 09:06:32 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1in17O-0005h6-Io for 38748@debbugs.gnu.org; Thu, 02 Jan 2020 09:06:31 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1in17J-0004hr-4J; Thu, 02 Jan 2020 09:06:25 -0500 Original-Received: from [176.228.60.248] (port=4122 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1in17B-0000Pp-BV; Thu, 02 Jan 2020 09:06:23 -0500 In-reply-to: (message from Andrii Kolomoiets on Wed, 01 Jan 2020 22:42:19 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174069 Archived-At: > From: Andrii Kolomoiets > Cc: alan@idiocy.org, 38748@debbugs.gnu.org, jguenther@gmail.com > Date: Wed, 01 Jan 2020 22:42:19 +0200 > > > (gdb) p last_marked_index > > $2 = 1 > > (gdb) p last_marked[0] > > $3 = XIL(0x8000000006287630) > > (gdb) xtype > > Lisp_String > > (gdb) xstring > > $4 = (struct Lisp_String *) 0x6287630 > > " *buffer-defaults*" > > I'm still have no luck to print last_marked item: > > (gdb) p last_marked_index > $1 = 278 > (gdb) p last_marked[277] > 'last_marked' has unknown type; cast it to its declared type This looks like some compiler bug, or maybe bug in GDB on your platform? Because the source clearly says Lisp_Object last_marked[LAST_MARKED_SIZE] EXTERNALLY_VISIBLE; so the type should be known to GDB. But this is just an aside. > But I found the commit after which error is occurs: > b2949d39261e82c33572ba8a250298ef0b165b95 > > Commenting out that 'ok = false;' line make Emacs works without errors. I cannot explain how that change could cause any harm. Here's the relevant code fragment: if (CONSP (parent_face)) { Lisp_Object tail; ok = false; for (tail = parent_face; !NILP (tail); tail = XCDR (tail)) { ok = get_lface_attributes (w, f, XCAR (tail), inherited_attrs, false, named_merge_points); if (!ok) break; attr_val = face_inherited_attr (w, f, inherited_attrs, attr_idx, named_merge_points); if (!UNSPECIFIEDP (attr_val)) break; } if (!ok) /* bad face? */ break; <<<<<<<<<<<<<<<<<<<<<<<<<<<<< } else { ok = get_lface_attributes (w, f, parent_face, inherited_attrs, false, named_merge_points); if (!ok) break; attr_val = inherited_attrs[attr_idx]; } Since parent_face is a cons cell, then we enter the for-loop (since a cons cell cannot be nil), and then we immediately call get_lface_attributes whose return value overwrites the initial value of 'ok'. So how could the initial value of 'ok' matter here? What am I missing? Can you run the unmodified code with a breakpoint on the line indicated by "<<<<<" above, and see if the breakpoint ever breaks? If it does break, can you show the face being merged in this case? Also, if you build Emacs with exactly the same configure options, but without optimizations, does the problem persist? Thanks.