unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 50571@debbugs.gnu.org
Subject: bug#50571: 28.0.50; Redisplay segfaults with empty face cache
Date: Tue, 14 Sep 2021 00:21:17 +0100	[thread overview]
Message-ID: <87a6kggiz6.fsf@tcd.ie> (raw)
In-Reply-To: <831r5sea46.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Sep 2021 19:03:21 +0300")

[-- Attachment #1: Type: text/plain, Size: 3863 bytes --]

Eli Zaretskii [2021-09-13 19:03 +0300] wrote:

>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:400
>> #1  0x00005555557d4f5f in die
>>     (msg=0x55555592d2e8 "0 <= id && id < FRAME_FACE_CACHE (f)->used",
>> file=0x55555592d2da "frame.h", line=1433) at alloc.c:7479
>> #2  0x00005555556c89f1 in FACE_FROM_ID (f=0x5555562070b0, id=0) at frame.h:1433
>> #3  0x00005555556d9e57 in face_at_buffer_position
>>     (w=0x555556207318, pos=1, endptr=0x7fffffff7f70, limit=101, mouse=false,
>> base_face_id=0, attr_filter=0) at xfaces.c:6425
>> #4  0x00005555555d41d0 in face_at_pos (it=0x7fffffff8170, attr_filter=0) at xdisp.c:4379
>> #5  0x00005555555d44cd in handle_face_prop (it=0x7fffffff8170) at xdisp.c:4480
>> #6  0x00005555555d2977 in handle_stop (it=0x7fffffff8170) at xdisp.c:3854
>> #7  0x00005555555dd96a in reseat (it=0x7fffffff8170, pos=..., force_p=true) at xdisp.c:7112
>> #8  0x00005555555d1abb in init_iterator
>>     (it=0x7fffffff8170, w=0x555556207318, charpos=1, bytepos=1,
>> row=0x555557419f80, base_face_id=DEFAULT_FACE_ID) at xdisp.c:3455
>
> init_iterator makes sure the frame's face cache includes all the basic
> faces, around line 3220 of xdisp.c:
>
>   /* If realized faces have been removed, e.g. because of face
>      attribute changes of named faces, recompute them.  When running
>      in batch mode, the face cache of the initial frame is null.  If
>      we happen to get called, make a dummy face cache.  */
>   if (FRAME_FACE_CACHE (it->f) == NULL)
>     init_frame_faces (it->f);
>   if (FRAME_FACE_CACHE (it->f)->used == 0)
>     recompute_basic_faces (it->f);
>
> The backtrace you sent starts at line 3455 of xdisp.c.  So somewhere
> between these two places, or maybe inside reseat and the functions it
> calls, the frame's face cache gets cleared.  Can you please put a
> watchpoint on it->f->face_cache->used, after the above snippet makes
> sure the cache is valid and the basic faces are cached in it, and see
> where the cache gets cleared?  Be sure to use the -l (ell) switch of
> the "watch" command in GDB, so it's valid even when you are not in the
> lexical scope of init_iterator.
>
> When the watchpoint breaks, please show both the C backtrace and the
> Lisp backtrace (using the "xbacktrace" command if needed).

For some reason, if I set a watch- or break-point with a condition that
involves untagging a structure, e.g. XFRAME or XSTRING, GDB gives me
something like the following:

  Error in testing breakpoint condition:                                                                                            
  Couldn't get registers: No such process.                                                                                          
  An error occurred while in a function called from GDB.                                                                            
  Evaluation of the expression containing the function                                                                              
  (SDATA) will be abandoned.                                                                                                        
  When the function is done executing, GDB will silently stop.                                                                      
  Selected thread is running.

Where SDATA may also be XFRAME/XSTRING depending on the condition.  Not
sure what that's about.

In any case, I was able to manually continue execution until
init_iterator was dealing with the desired frame.  If you know of a way
to streamline this, please let me know.

Note that, at the time that I issue 'bt full' in the attached log, the
single visible *scratch* frame has the following in the echo area:

  Error during bug-reference-auto-setup: (no-catch sucess t)

So there's an uncaught signal (presumably due to a typo) in the mix too.

Thanks,

-- 
Basil


[-- Attachment #2: GDB log --]
[-- Type: application/gzip, Size: 18716 bytes --]

  reply	other threads:[~2021-09-13 23:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13 14:59 bug#50571: 28.0.50; Redisplay segfaults with empty face cache Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-13 16:03 ` Eli Zaretskii
2021-09-13 23:21   ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-09-14 13:03     ` Eli Zaretskii
2021-09-14 13:33       ` Eli Zaretskii
2021-09-14 19:45         ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 13:16           ` Eli Zaretskii
2021-09-19 13:57           ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-19 15:47             ` Eli Zaretskii
2021-09-19 18:21               ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-19 18:41                 ` Eli Zaretskii

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=87a6kggiz6.fsf@tcd.ie \
    --to=bug-gnu-emacs@gnu.org \
    --cc=50571@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=eliz@gnu.org \
    /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).