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#71712: 29.3; Crash on OpenBSD Date: Sat, 22 Jun 2024 13:00:53 +0300 Message-ID: <861q4pi9ey.fsf@gnu.org> References: <864j9lju9u.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30021"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71712@debbugs.gnu.org To: kirill@korins.ky, Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 22 12:02:23 2024 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 1sKxZe-0007ZD-Pj for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jun 2024 12:02:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKxZP-0002Ir-EG; Sat, 22 Jun 2024 06:02:07 -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 1sKxZK-0002IN-NX for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 06:02:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sKxZK-0003lu-4k for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 06:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKxZJ-0002Gi-QK for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 06:02:01 -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, 22 Jun 2024 10:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71712 X-GNU-PR-Package: emacs Original-Received: via spool by 71712-submit@debbugs.gnu.org id=B71712.17190504668649 (code B ref 71712); Sat, 22 Jun 2024 10:02:01 +0000 Original-Received: (at 71712) by debbugs.gnu.org; 22 Jun 2024 10:01:06 +0000 Original-Received: from localhost ([127.0.0.1]:44500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKxYP-0002FQ-Qm for submit@debbugs.gnu.org; Sat, 22 Jun 2024 06:01:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKxYL-0002Ej-QG for 71712@debbugs.gnu.org; Sat, 22 Jun 2024 06:01:04 -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 1sKxYG-0003hh-Az; Sat, 22 Jun 2024 06:00:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zgR3F3Fq4ZlaDe2ycbqzTLjvXQ7E4dQDmHQqqTwHXgY=; b=jCzklqXMsXuH U/KUKr8KZ7fGqwMU1ZQuwqRaEeKKUaXKwaHioGq3Ujudf0WjuRcxAepchee2yWWerzOfsEsZU+2wO Rlra/OuPhA0h3TwOJElsapq7Ol5q0x/MZbvh3E+3obhHpSY/HaXJOIls5yguWHAl+GP44nOKQ7I8v TxiearH2FA6jOn79A1fMuOTO1LkLQM2rLFjUPC7Y89IWIXPtykT1D+oWlkC77f/Zf5dvXSu4dA6zY 62v3jbkdpT8hkt3HL8uoSHWUII0jgd63G1FKEzkm23PTfQCyHSPGJRwXcbHq4WIxGbvXD/GSW563y X8Vg7Lbsrbo7aUtPRfSgMg==; In-Reply-To: (message from Kirill A. Korinsky on Sat, 22 Jun 2024 10:28:43 +0100) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287688 Archived-At: > Date: Sat, 22 Jun 2024 10:28:43 +0100 > From: Kirill A. Korinsky > Cc: 71712@debbugs.gnu.org > > On Sat, 22 Jun 2024 08:45:01 +0100, > Eli Zaretskii wrote: > > > > Thanks. Is this reproducible? If so, can you show a recipe, > > preferably starting from "emacs -Q"? > > > > It crashes some times but I'd like to say that this is the first crash in > this month. > > So, I have no idea how to reproduce, frankly speaking I just hasn't found > running emacs and discovered .core Too bad. But quite expected, unfortunately. > The only clue that I have that I was switched to different virtual screen > and emacs was on not seen one. > > Additionally, inside .xsession-errors I do have: > > 0xbf72627f9a1 at emacs > 0xbf72625a8ee at emacs > 0xbf72627f6c7 at emacs > Segmentation fault (core dumped) Po Lu, any ideas based on this? > > FWIW, I looked at the code, and I cannot understand how this could > > happen. The cause of the crash is that 'face' is NULL, so face->font > > segfaults. But 'face' is obtained from 'face_id', which is zero, > > i.e. it's the default face: > > > > > glyph = {ch = 36, face_id = 0} > > > > And init_iterator, which called produce_special_glyphs, makes sure the > > basic faces, including the default face, are recomputed just before > > the call to produce_special_glyphs: > > > > 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); > > > > And recompute_basic_faces aborts if it is unsuccessful in recomputing > > the basic faces, one of which is the default face. Which didn't > > happen here. So how this could happen is a mystery to me; I'm > > probably missing something. > > This is indeed NULL: > > (gdb) up 9 > #9 0x00000bf72613ced7 in produce_special_glyphs (it=0x723f0516cf78, what=) at xdisp.c:31605 > 31605 xdisp.c: No such file or directory. > (gdb) p it > $1 = (struct it *) 0x723f0516cf78 > (gdb) p it->f > $2 = (struct frame *) 0xbf99e5ccba8 > (gdb) p it->f->face_cache > $3 = (struct face_cache *) 0xbf9945600f0 > (gdb) p *it->f->face_cache > $4 = {buckets = 0xbf9e196d000, f = 0xbf99e5ccba8, faces_by_id = 0xbf93c9b3000, size = 168, used = 0, menu_face_changed_p = false} That "used = 0" means the face cache is empty. And I don't understand how that could happen in this scenario, given that init_iterator makes sure that if the cache is empty, the basic faces are recomputed (which refills the cache with the basic faces). > (gdb) p it->f->face_cache->faces_by_id > $5 = (struct face **) 0xbf93c9b3000 > (gdb) p it->f->face_cache->faces_by_id[0] > $7 = (struct face *) 0x0 > (gdb) p it->face_id > $8 = 0 > (gdb) > > so, I also dig a bit. I see that faces_by_id is enlarged as: > > /* Maybe enlarge C->faces_by_id. */ > if (i == c->used) > { > if (c->used == c->size) > c->faces_by_id = xpalloc (c->faces_by_id, &c->size, 1, MAX_FACE_ID, > sizeof *c->faces_by_id); > c->used++; > } > > here, it's trust value from xpalloc, and inside I see that it uses xrealloc > which has this logc: > > if (!val) > memory_full (size); > MALLOC_PROBE (size); > return val; > > so, if val is NULL it calls memory_full and if it doesn't crash, it returns > NULL which not always fails as I understand it. > > Does it make sense? Yes, but memory_full signals an error, which (a) you should have seen, and (b) it prevents the rest of the code from being executed, because it throws to top-level. Thus, for all practical purposes the return value of xmalloc does not matter if the memory could not be allocated. So I don't believe this is what happened to you, even if we assume that you have indeed ran out of memory (which in itself is quite improbably on modern systems).