From: Kirill A. Korinsky <kirill@korins.ky>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 71712@debbugs.gnu.org
Subject: bug#71712: 29.3; Crash on OpenBSD
Date: Sat, 22 Jun 2024 10:28:43 +0100 [thread overview]
Message-ID: <e13900b7a54526b6@mx1.catap.net> (raw)
In-Reply-To: <864j9lju9u.fsf@gnu.org>
On Sat, 22 Jun 2024 08:45:01 +0100,
Eli Zaretskii <eliz@gnu.org> 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
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 <XSetWMNormalHints+0x2fd71> at emacs
0xbf72625a8ee <XSetWMNormalHints+0xacbe> at emacs
0xbf72627f6c7 <XSetWMNormalHints+0x2fa97> at emacs
Segmentation fault (core dumped)
> 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=<optimized out>) 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}
(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?
--
wbr, Kirill
next prev parent reply other threads:[~2024-06-22 9:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-22 0:01 bug#71712: 29.3; Crash on OpenBSD Kirill A. Korinsky
2024-06-22 1:24 ` Stefan Kangas
2024-06-22 7:45 ` Eli Zaretskii
2024-06-22 9:28 ` Kirill A. Korinsky [this message]
2024-06-22 10:00 ` Eli Zaretskii
2024-06-22 11:00 ` Kirill A. Korinsky
2024-06-22 12:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-22 14:41 ` Kirill A. Korinsky
2024-06-22 15:55 ` Eli Zaretskii
2024-06-26 9:11 ` Kirill A. Korinsky
2024-06-26 13:14 ` Eli Zaretskii
2024-06-26 15:58 ` Kirill A. Korinsky
2024-06-26 16:11 ` Eli Zaretskii
2024-06-26 22:00 ` Kirill A. Korinsky
2024-06-27 5:33 ` Eli Zaretskii
2024-06-27 11:44 ` Kirill A. Korinsky
2024-06-27 12:33 ` Eli Zaretskii
2024-06-27 13:36 ` Kirill A. Korinsky
2024-06-27 14:19 ` Gerd Möllmann
2024-06-27 14:43 ` Kirill A. Korinsky
2024-06-27 15:01 ` Gerd Möllmann
2024-06-30 8:52 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-30 16:42 ` Kirill A. Korinsky
2024-06-30 17:40 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-30 22:58 ` Kirill A. Korinsky
2024-07-01 9:10 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-01 11:18 ` Eli Zaretskii
2024-07-01 13:29 ` Kirill A. Korinsky
2024-07-01 13:43 ` Eli Zaretskii
2024-07-01 15:17 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-01 16:04 ` Eli Zaretskii
2024-07-01 16:42 ` Kirill A. Korinsky
2024-07-01 17:36 ` Eli Zaretskii
2024-07-01 18:38 ` Kirill A. Korinsky
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=e13900b7a54526b6@mx1.catap.net \
--to=kirill@korins.ky \
--cc=71712@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 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).