From: Ken Raeburn <raeburn@permabit.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 18162@debbugs.gnu.org
Subject: bug#18162: 24.3.92; segfault on null face pointer in face_for_char
Date: Sat, 2 Aug 2014 06:00:34 -0400 [thread overview]
Message-ID: <0917D61C-D040-44A7-B7D6-B4AD5BDB0BEA@permabit.com> (raw)
In-Reply-To: <83vbqbqtc1.fsf@gnu.org>
On Aug 2, 2014, at 02:49, Eli Zaretskii <eliz@gnu.org> wrote:
> There's nothing wrong with a call to clear_face_cache. We do this all
> the time, as you have discovered. The problem is if we try using
> faces after that without first realizing the basic faces.
Okay, I guess I misread your earlier message as suggesting that that was the problem. In any case, starting from that, I've got a recipe that seems to be somewhat reliable at triggering the problem:
emacs -Q
M-x list-faces-display RET
Type into the scratch buffer:
(progn (clear-face-cache t) (internal-char-font nil 8230))
Hit C-j to evaluate. This generally works the first time. Move the cursor back up to the end of the expression and hit C-j again. The second time usually crashes for me.
The use of list-faces-display came about through guesswork and it seems to help. The real trick, I think, is to get FRAME_DISPLAY_INFO(f)->n_fonts to be large enough to trigger the call to free_all_realized_faces.
Ken
next prev parent reply other threads:[~2014-08-02 10:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 23:24 bug#18162: 24.3.92; segfault on null face pointer in face_for_char Ken Raeburn
2014-08-01 5:57 ` Eli Zaretskii
2014-08-01 8:46 ` Ken Raeburn
2014-08-02 1:52 ` Ken Raeburn
2014-08-02 6:49 ` Eli Zaretskii
2014-08-02 10:00 ` Ken Raeburn [this message]
2014-08-02 10:41 ` Eli Zaretskii
2014-08-02 12:50 ` Eli Zaretskii
2014-08-03 6:51 ` Ken Raeburn
2014-08-03 15:04 ` Eli Zaretskii
2014-08-07 4:12 ` Ken Raeburn
2014-08-07 15:19 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0917D61C-D040-44A7-B7D6-B4AD5BDB0BEA@permabit.com \
--to=raeburn@permabit.com \
--cc=18162@debbugs.gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.