From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem) Date: Fri, 24 Feb 2023 09:52:13 +0200 Message-ID: <83wn47o5zm.fsf@gnu.org> References: <877h40vb8h.fsf@mail.jurta.org> <4EA4D31B.4050604@cs.ucla.edu> <4EA5E08D.8070903@cs.ucla.edu> <861qmvcglp.fsf@aarsen.me> <98e880a0-d076-cfd9-b39d-50c84fa8975a@gmail.com> <811d85e0-4032-68df-bc0c-1073ff5d1b96@cs.ucla.edu> <5a38c18d-263c-223b-7335-8395a10eb494@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1069"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Jim Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 24 08:53:17 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVStI-00006S-SC for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Feb 2023 08:53:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVSsY-0005X7-Gf; Fri, 24 Feb 2023 02:52:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVSsQ-0005Od-BJ for emacs-devel@gnu.org; Fri, 24 Feb 2023 02:52:23 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVSsP-0003Rw-0k; Fri, 24 Feb 2023 02:52:21 -0500 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=cdzWvbr7q8d6Jk2tyv1Yax+QGs4936skx2gpcl/QLgM=; b=DIAhCkoRxYJf KcmxSpu+1CycYrF+/PsbAehmmxoEQ8wSM2UbHcIf1zdByswz9F2UVnq83QH6wlG2rrT2KEA7oEEG8 eJg6M3G4lMyJTBgpFfQ8xCGBWVN3/pQjxQQ3CmYD9F228Acz7Ew/yC44Dwqrcj4mn4cGjU7tGgR7h N35Pf6e4/hgIqTf6fz5nZkALTDMSBCruWXAgTaPedSvx4fLT8ug2y/VrOsWNmTD0ms5YvnD5+AZc2 y/f7hudetMx4OYGyTiYbIWtTY+bRlULuC79efHxoAR1SxcTQxeooUOJV2Lp3p0hgHKaYRaKyXCRHa K+pEkPknpjrmksJz3QgkPw==; Original-Received: from [87.69.77.57] (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 1pVSsJ-0000yc-En; Fri, 24 Feb 2023 02:52:18 -0500 In-Reply-To: (message from Jim Porter on Thu, 23 Feb 2023 18:20:39 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303741 Archived-At: > Date: Thu, 23 Feb 2023 18:20:39 -0800 > From: Jim Porter > Cc: emacs-devel@gnu.org > > On 2/23/2023 4:50 PM, Jim Porter wrote: > > Since the last message I posted, I'm now also seeing this test fail, > > though I get a segfault instead. I bisected this to commit > > a555abc56d5270cebe94f904189526d7ac433a94 ("Fix order of faces in > > 'face-list'"). > > > > I'm pretty surprised by this, since that patch is *very* simple, but I > > can reliably segfault with it, and never segfault without it. I'll keep > > digging to see what's going on here. > > The segfault is in FACE_FROM_ID_OR_NULL, called from > Finternal_merge_in_global_face. It happens because the face_cache is > null during these tests (since Emacs is noninteractive). > > The attached patch fixes the issue for me, though I'm not totally sure > it's the *right* fix. Any thoughts? (I'm also not 100% sure this is the > same issue you're seeing...) Please show the C backtrace from the crash, and include the Lisp backtrace (the "xbacktrace" command in src/.gdbinit). Why do you think a frame's face cache doesn't exist in noninteractive sessions? Such a session does have a (small) frame, and that frame does have a face cache. Here, try this with the emacs-29 branch: $ gdb ./emacs ... (gdb) break xfaces.c:4193 (gdb) r -batch --eval "(insert (propertize \" \" 'face '(:forground \"red\")))" When the breakpoint breaks, you will see: (gdb) p c $1 = (struct face_cache *) 0x6beeb78 (gdb) p c->used $2 = 19 So in this case there is a face cache for the frame, and it has 19 faces cached. Therefore, I think there's more here than meets the eye. The frame's face cache might be empty because some code caused us to do so (we do that when a new face is added), in which case TRT to do is to recompute all the basic faces. But first we need to try to understand what exactly caused the cache to be emptied.