emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated fil


From: Eli Zaretskii
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

> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]