From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 01 03:40:38 2022 Received: (at 54661) by debbugs.gnu.org; 1 Apr 2022 07:40:38 +0000 Received: from localhost ([127.0.0.1]:40759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1naBte-0007uB-BT for submit@debbugs.gnu.org; Fri, 01 Apr 2022 03:40:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1naBtd-0007tz-7K for 54661@debbugs.gnu.org; Fri, 01 Apr 2022 03:40:37 -0400 Received: from [2001:470:142:3::e] (port=48352 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naBtX-00018q-7J; Fri, 01 Apr 2022 03:40:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=o8dtEx8gfQ6GAHJ2ELkTjEkcXfVLruR0+QHPlmoVG1o=; b=ccCMHG5k9xdY 4Q14T9w4okdOxvU/jP1bbmyi/ANRikJiz/ya4P7X+lCd+zV7o+pwssccVR18vpY1dEto8cFWUIPZk pFBcpcIUR/vq+8g4P8zdYJiy/K4rxm2ziOZK7wRMxN4Ves5x+Gr1pHLn54b+GhpHeyGsDzNH6sRf9 3A1Qgt6r9Wmq4xw7ZWIyVlpKpDF64zU9emVB6x8TSVNpq1J4NyrpzrESps4mM/8XJ627ECF3j82u/ BcNloWMXvaXq5+kHl3UIzbJJqqm0AmWmYcLS+l5a3nzyBuPZFNyCWtfZq7Cq13ifRG/SCUh/GLAJs PHk0D5yJZEdDKEPpqwdSFA==; Received: from [87.69.77.57] (port=1109 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naBtP-0004KG-9c; Fri, 01 Apr 2022 03:40:29 -0400 Date: Fri, 01 Apr 2022 10:40:35 +0300 Message-Id: <83mth55k0c.fsf@gnu.org> From: Eli Zaretskii To: James Ferguson In-Reply-To: (message from James Ferguson on Thu, 31 Mar 2022 17:19:03 -0400) Subject: Re: bug#54661: 29.0.50; Emacs SEGV in get_glyph_face_and_encoding References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54661 Cc: 54661@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: James Ferguson > Date: Thu, 31 Mar 2022 17:19:03 -0400 > > My Emacs has SEGVing a few times (twice today), from a fairly recent > build off `master`. Sometimes it seems to have happened when doing > autocompletion (using the `corfu` package), but it has definitely > happened when idle from a user perspective. > > I'm afraid I have a lot of packages active including lsp, and it's way > too random and sporadic to be able to craft a cut-down config. > > I will put the `bt full` output at the bottom of this email. I have > quite a few cores, but a quick check looks like they all have similar stack. > That `face = 0x0` looks ... ominous(?). Yes, that's the immediate reason for the segfault. The question is: how did that happen? It usually happens because some code cleared the frame's face cache between the time the window's glyph matrix was created/updated, which holds the face for each glyph to be displayed, and the time the window's display is actually drawn to the glass. The former part happens in redisplay_windows, called on line 16518 of xdisp.c; the latter part happens inside update_frame, called on line 16598 of xdisp.c. The way to debug this is to find which code empties the face cache, and then figure out the control flow path which leads to that code in your scenario. Can you try figuring that out? One way of doing so is to set up a breakpoint in free_realized_faces, here: for (i = 0; i < c->used; ++i) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< { free_realized_face (f, c->faces_by_id[i]); c->faces_by_id[i] = NULL; } and enable this breakpoint only between the above two lines of xdisp.c. (You can do that via breakpoint commands of 2 more breakpoints in xdisp.c, in the places I mentioned above: a breakpoint on xdisp.c:16531 with commands that enable the breakpoint in free_realized_face, and another on xdisp.c:16598 which disables that breakpoint.) Then in the breakpoint commands for the breakpoint in free_realized_face, produce the C and Lisp backtrace (the latter with xbacktrace command defined on src/.gdbinit), and post it here. That might tell us which code is doing this. Thanks.