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.bugs Subject: bug#42943: 28.0.50; Emacsclient crashes in ftcrfont_glyph_extents Date: Sat, 24 Oct 2020 16:10:31 +0300 Message-ID: <83imazhirc.fsf@gnu.org> References: <877dtuta6z.fsf@tcd.ie> <87y2m82ix4.fsf@gnus.org> <87zh4emnzm.fsf@gnus.org> <87lffxlxm5.fsf@tcd.ie> <83lffvhmne.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15729"; mail-complaints-to="usenet@ciao.gmane.io" Cc: contovob@tcd.ie, larsi@gnus.org, 42943@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 24 15:11:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kWJKC-00042s-Ce for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Oct 2020 15:11:12 +0200 Original-Received: from localhost ([::1]:59716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWJKB-00043Z-Di for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Oct 2020 09:11:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWJK3-00041h-2Y for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 09:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49634) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWJK2-0004aX-DS for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 09:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWJK2-0006qt-9M for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 09:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Oct 2020 13:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42943 X-GNU-PR-Package: emacs Original-Received: via spool by 42943-submit@debbugs.gnu.org id=B42943.160354505426304 (code B ref 42943); Sat, 24 Oct 2020 13:11:02 +0000 Original-Received: (at 42943) by debbugs.gnu.org; 24 Oct 2020 13:10:54 +0000 Original-Received: from localhost ([127.0.0.1]:32947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWJJt-0006q4-Cn for submit@debbugs.gnu.org; Sat, 24 Oct 2020 09:10:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWJJq-0006pW-DB for 42943@debbugs.gnu.org; Sat, 24 Oct 2020 09:10:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46440) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWJJk-0004Y1-NX; Sat, 24 Oct 2020 09:10:44 -0400 Original-Received: from [176.228.60.248] (port=4330 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kWJJk-0005f0-5r; Sat, 24 Oct 2020 09:10:44 -0400 In-Reply-To: (message from Robert Pluim on Sat, 24 Oct 2020 14:14:53 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191422 Archived-At: > From: Robert Pluim > Cc: contovob@tcd.ie, larsi@gnus.org, 42943@debbugs.gnu.org > Date: Sat, 24 Oct 2020 14:14:53 +0200 > > Eli> I'm guessing that we close the font, but there's still a face that > Eli> references that font, and we try using that face for display. Can you > Eli> see if that is the case? The 'face' member of 'struct glyph_string' > Eli> should point to the face, and face->font should point to the font. > > Yes, weʼre using the face thatʼs cached in the glyph_string: But glyph_strings are not kept between redisplay cycles, AFAIR, they are recreated anew each time we need to redisplay something. This happens in the write_glyphs method that is called from update_window and update_frame, which eventually calls gui_write_glyphs, which calls draw_glyphs, which creates the glyph_strings in BUILD_GLYPH_STRINGS. So it's unclear to me how can a face be cached in a glyph_string. > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. > ftcrfont_glyph_extents (font=0x555556930478, glyph=1036, > metrics=metrics@entry=0x0) at ftcrfont.c:81 > 81 if (METRICS_STATUS (cache) == METRICS_INVALID) > (gdb) up > #1 0x00005555558453a1 in ftcrfont_draw (s=0x7fffffffb440, > from=, to=, x=17, y=, > with_background=) at ftcrfont.c:520 > 520 x += (s->padding_p ? 1 : ftcrfont_glyph_extents (s->font, > (gdb) l 500 > 495 struct face *face = s->face; > 496 struct font_info *ftcrfont_info = (struct font_info *) s->font; > 497 cairo_t *cr; > 498 cairo_glyph_t *glyphs; > 499 int len = to - from; > 500 int i; > 501 > 502 block_input (); > 503 > 504 cr = x_begin_cr_clip (f, s->gc); > (gdb) p s->face > $1 = (struct face *) 0x555556113290 > (gdb) p s->face->font > $2 = (struct font *) 0x555556930478 > (gdb) p s->font > $3 = (struct font *) 0x555556930478 And how do you see from the above that it's a pointer to the same 'struct font' that was used by the now-deleted first client frame? > Eli> We call font_clear_cache when a frame is deleted, so it's unclear to > Eli> me how come the font is still remembered somewhere. > > font_clear_cache closes all the fonts and sets the frame's font cache > to Qnil, I donʼt see it doing anything with faces. Faces are cached in the frame's face cache, see xfaces.c. When a frame is deleted, its face cache is freed, so its faces should also go away. A new frame starts with an empty face cache, and then faces are added to that cache as they are "realized", starting from the "basic faces" that are always needed, see realize_basic_faces. For a non-ASCII character, we produce a new face based on the default face, the first time we need to display a character that needs a font we don't already have; then that face is also added to the frame's face cache. > Eli> And I lack some background here: what is/are the character(s) we try > Eli> displaying here, and how that display is triggered by creating a new > Eli> frame due to the second emacsclient invocation? > > Itʼs just emacsclient redisplaying *scratch*, I think. And *scratch* has an Arabic character? How did that happen? I thought the recipe was only to turn on the Arabic input method. Is the offending character the IM indicator on the mode-line, per chance? > Are you saying redisplay should not be called here? No, of course not. When a new frame is created, it is immediately displayed.