unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Porter <jporterbugs@gmail.com>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
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	[thread overview]
Message-ID: <83wn47o5zm.fsf@gnu.org> (raw)
In-Reply-To: <c0791700-72df-1cc2-784b-f3417a90eda6@gmail.com> (message from Jim Porter on Thu, 23 Feb 2023 18:20:39 -0800)

> Date: Thu, 23 Feb 2023 18:20:39 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> 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.



  parent reply	other threads:[~2023-02-24  7:52 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <877h40vb8h.fsf@mail.jurta.org>
     [not found] ` <4EA4D31B.4050604@cs.ucla.edu>
     [not found]   ` <E1RISPO-0007Eu-TE@fencepost.gnu.org>
     [not found]     ` <4EA5E08D.8070903@cs.ucla.edu>
     [not found]       ` <861qmvcglp.fsf@aarsen.me>
     [not found]         ` <f711f43f-6892-f849-21ec-26376c351f11@cs.ucla.edu>
2023-02-13 21:55           ` server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem) Jim Porter
2023-02-14  2:47             ` Paul Eggert
2023-02-15  7:06               ` Jim Porter
2023-02-15 18:20                 ` Paul Eggert
2023-02-23 23:42                   ` Paul Eggert
2023-02-24  0:50                     ` Jim Porter
2023-02-24  2:20                       ` Jim Porter
2023-02-24  3:25                         ` Po Lu
2023-02-24  3:38                           ` Jim Porter
2023-02-24  7:52                         ` Eli Zaretskii [this message]
2023-02-24 17:48                           ` Jim Porter
2023-02-24 18:37                             ` Eli Zaretskii
2023-02-24 19:45                               ` Alan Mackenzie
2023-02-24 20:31                               ` Jim Porter
2023-02-24 20:47                                 ` Eli Zaretskii
2023-02-26  8:29                       ` Paul Eggert
2023-02-26  9:47                         ` Eli Zaretskii
2023-02-27  5:31                         ` Jim Porter
2023-02-27 16:40                           ` server.el test failures Robert Pluim
2023-02-27 16:50                             ` Eli Zaretskii
2023-02-27 18:14                               ` Robert Pluim
2023-02-27 18:39                                 ` Eli Zaretskii
2023-02-28  7:42                                   ` Robert Pluim
2023-02-28 12:13                                     ` Eli Zaretskii
2023-02-28 13:05                                       ` Robert Pluim
2023-02-28 19:02                                         ` Jim Porter
2023-02-28 19:23                                           ` Eli Zaretskii
2023-02-28 19:41                                             ` Jim Porter
2023-03-01  8:22                                               ` Robert Pluim
2023-03-02 22:15                                                 ` Jim Porter
2023-03-03  7:00                                                   ` Eli Zaretskii
2023-03-03  7:15                                                     ` Jim Porter
2023-03-03  8:00                                                       ` Jim Porter
2023-03-03  8:10                                                         ` Eli Zaretskii
2023-03-03 17:27                                                           ` Jim Porter
2023-03-03  8:16                                                         ` Robert Pluim

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wn47o5zm.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=jporterbugs@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).