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.devel Subject: Re: Building the igc branch on MS-Windows Date: Sat, 27 Apr 2024 15:37:56 +0300 Message-ID: <86plubugkb.fsf@gnu.org> References: <86il063imh.fsf@gnu.org> <86ttjp20je.fsf@gnu.org> <87y191fwnd.fsf@gmail.com> <87cyqcfv6k.fsf@gmail.com> <86o79wzi31.fsf@gnu.org> <86mspgza23.fsf@gnu.org> <867cgkz7e2.fsf@gnu.org> <87r0esdv7o.fsf@gmail.com> <87le50dmec.fsf@gmail.com> <8734r7etu1.fsf@gmail.com> <86il03xrlz.fsf@gnu.org> <868r0zxpfr.fsf@gnu.org> <8634r7xoil.fsf@gnu.org> <86y18zukdk.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="39388"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 27 14:38:35 2024 Return-path: Envelope-to: ged-emacs-devel@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 1s0hK6-000A0h-KM for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Apr 2024 14:38:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0hJb-0004lG-59; Sat, 27 Apr 2024 08:38:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s0hJX-0004kW-Cy for emacs-devel@gnu.org; Sat, 27 Apr 2024 08:37:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s0hJX-0008TI-4U; Sat, 27 Apr 2024 08:37:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=4VZhk1bTEw6a/Ep3EMjetzSiKSU4985iWpsWbB6bmtE=; b=G7RVLWSAIkSqprgbXv51 xA0NvN9WYS8q8zfaUcQAorU1UOfu9jnvTg6N99Lsgu4/Mxpyt3I5ku/w5Lt/7I7L/AfN5sLTrkBJh 7SxLqDjNkxt6g5nmZXr3kSGhcCHcZdbxIU7KWxl98QgNR3/F5SCAqmuGWDPZ5fPggDyHPTY78T8Gc ssGgOHIU7S7x/zAg40JsL3E9P6ooi1fhG9+HMfuUAGhl0FASM1omCav7/W0j6jacNYfaswT3nalaT LGfyLvXrzMqR7NMP7hSJXzvqJcph3mInNNp0umgwFDpPYk6rx9kT93sHUN0yypHhLYLrPvjTa0DEk 6aEWaGH4I6Zn/A==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sat, 27 Apr 2024 14:09:26 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318197 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Sat, 27 Apr 2024 14:09:26 +0200 > > Inaccessible memory in my experience so far means that the corresponding > object has either been moved by MPS, or it has been "freed", by not > copying it. > > So, as an ansatz, let's assume the font in question has been moved. It > would follow, I think, that it is not a face->font right? Because > otherwise the reference to the the font would have been traced. The > question would be where the reference to the font comes from? It _is_ face->font. We get to it like this: void gui_produce_glyphs (struct it *it) { int extra_line_spacing = it->extra_line_spacing; it->glyph_not_available_p = false; if (it->what == IT_CHARACTER) { unsigned char2b; struct face *face = FACE_FROM_ID (it->f, it->face_id); struct font *font = face->font; <<<<<<<<<<<<<<<<<<<<<<<<<<<< IOW, the display iterator references a face by its ID, and we access that face via the frame's face cache. As I wrote in a previous message, all the faces in the cache after index 21 are clobbered, although the cache's 'used' count is 57, and the index of the problematic face is 22.