From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Pip Cet <pipcet@protonmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
Ihor Radchenko <yantar92@posteo.net>,
emacs-devel@gnu.org, eller.helmut@gmail.com
Subject: Re: MPS: Crash when switching to buffer
Date: Mon, 01 Jul 2024 16:42:34 +0200 [thread overview]
Message-ID: <m28qylcgx1.fsf@pro2.fritz.box> (raw)
In-Reply-To: <OifzVrpJwTw0NuVdcQss9KlkJ50L2Qb-5cUj-rkoJgaqs_2kYJnLx8AfYVP_Acnv5MnKaJzCBld7ao53dbS7KITa8Pre7LdV7TLMjjMzvJs=@protonmail.com> (Pip Cet's message of "Mon, 01 Jul 2024 14:14:47 +0000")
Pip Cet <pipcet@protonmail.com> writes:
> On Monday, July 1st, 2024 at 12:04, Eli Zaretskii <eliz@gnu.org> wrote:
>> > From: Ihor Radchenko yantar92@posteo.net
>>
>> > Cc: Gerd Möllmann gerd.moellmann@gmail.com, Eli Zaretskii
>> > eliz@gnu.org,
>> > eller.helmut@gmail.com
>> > Date: Mon, 01 Jul 2024 09:26:25 +0000
>> >
>> > Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:443
>> > 443 {
>> > (gdb) bt
>> > #0 terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:443
>> > #1 0x00005555556e446b in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1800
>> > #2 0x00005555556e44d0 in deliver_thread_signal (sig=11, handler=0x5555556e4457 <handle_fatal_signal>) at sysdep.c:1792
>> > #3 deliver_fatal_thread_signal (sig=sig@entry=11) at sysdep.c:1812
>> > #4 0x00005555556e44fd in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1950
>> > #5 0x00007ffff3048050 in <signal handler called> () at /lib64/libc.so.6
>> > #6 0x00007ffff304822b in kill () at /lib64/libc.so.6
>> > #7 0x0000555555880af9 in sigHandle (sig=<optimized out>, info=<optimized out>, uap=<optimized out>) at /home/yantar92/Dist/mps/code/protsgix.c:114
>> > #8 0x00007ffff3048050 in <signal handler called> () at /lib64/libc.so.6
>> > #9 XCDR (c=XIL(0x32ec042e3)) at /home/yantar92/Git/emacs/src/lisp.h:1522
>> > #10 plist_get (plist=<optimized out>, prop=prop@entry=XIL(0x8220)) at fns.c:2611
>> > #11 0x000055555575a8de in Fget (symbol=symbol@entry=XIL(0x2aaa92d6f288), propname=propname@entry=XIL(0x8220)) at fns.c:2631
>> > #12 0x0000555555664370 in resolve_face_name (face_name=XIL(0x2aaa92d6f288), signal_p=signal_p@entry=false) at xfaces.c:2004
>> > #13 0x0000555555669e57 in get_lface_attributes
>> > (w=w@entry=0x7fffef8a0068, f=f@entry=0x7fffe26fd610,
>> > face_name=<optimized out>, attrs=attrs@entry=0x7fffffff5270,
>> > signal_p=signal_p@entry=false, named_merge_points=<optimized out>,
>> > named_merge_points@entry=0x0) at xfaces.c:2105
>> > #14 0x0000555555670ea9 in lookup_derived_face
>> > (w=0x7fffef8a0068, f=f@entry=0x7fffe26fd610, symbol=<optimized out>, face_id=face_id@entry=45, signal_p=signal_p@entry=false) at xfaces.c:5279
>> > #15 0x0000555555671ef4 in merge_faces (w=<optimized out>, face_name=<optimized out>, face_name@entry=XIL(0x30), face_id=<optimized out>, base_face_id=45)
>> > at xfaces.c:7128
>> > #16 0x00005555555c0751 in next_element_from_display_vector (it=0x7fffffff7dc0) at xdisp.c:9045
>
> At first glance, the lface_id_to_name "vector" (just a pointer to
> Lisp_Object, not a Lisp_Vector) isn't allocated using igc methods, so
> references in it might not be traced. Is that possible, Gerd? I
> confess I'm not totally sure how xmalloc and friends get translated in
> the MPS build...
That's very possible, and a bug :-). Good catch!
If xmalloc/xfree and friends are used to alloc memory that contains
references, we have replaced them with oen of these
void *igc_xzalloc_ambig (size_t size);
void *igc_realloc_ambig (void *block, size_t size);
void igc_xfree (void *p);
Lisp_Object *igc_xalloc_lisp_objs_exact (size_t n);
void *igc_xpalloc_ambig (void *pa, ptrdiff_t *nitems,
ptrdiff_t nitems_incr_min, ptrdiff_t nitems_max,
ptrdiff_t item_size);
void igc_xpalloc_exact (void **pa_cell, ptrdiff_t *nitems,
ptrdiff_t nitems_incr_min, ptrdiff_t nitems_max,
ptrdiff_t item_size, igc_scan_area_t scan);
void *igc_xnrealloc_ambig (void *pa, ptrdiff_t nitems, ptrdiff_t item_size);
Hope I got them all. All of them create roots, the ambig variants
ambiguous roots, the exact variants exact roots. igc_xfree must be used
instead of xfree so that the roots get destroyed when the memory is freed.
next prev parent reply other threads:[~2024-07-01 14:42 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 9:26 MPS: Crash when switching to buffer Ihor Radchenko
2024-07-01 12:04 ` Eli Zaretskii
2024-07-01 12:13 ` Ihor Radchenko
2024-07-01 12:46 ` Eli Zaretskii
2024-07-01 14:14 ` Pip Cet
2024-07-01 14:42 ` Gerd Möllmann [this message]
2024-07-02 0:22 ` Pip Cet
2024-07-02 4:04 ` Gerd Möllmann
2024-07-02 11:40 ` Ihor Radchenko
2024-07-04 10:31 ` Ihor Radchenko
2024-07-04 11:48 ` Gerd Möllmann
2024-07-04 12:02 ` MPS: User GC customizations (was: MPS: Crash when switching to buffer) Ihor Radchenko
2024-07-04 12:51 ` MPS: User GC customizations Gerd Möllmann
2024-07-04 13:20 ` Ihor Radchenko
2024-07-04 14:45 ` Gerd Möllmann
2024-07-04 15:12 ` Pip Cet
2024-07-04 16:07 ` Gerd Möllmann
2024-07-04 16:38 ` Ihor Radchenko
2024-07-04 17:02 ` Gerd Möllmann
2024-07-04 17:53 ` Eli Zaretskii
2024-07-04 18:18 ` Gerd Möllmann
2024-07-04 18:28 ` Ihor Radchenko
2024-07-04 18:32 ` Pip Cet
2024-07-04 18:43 ` Gerd Möllmann
2024-07-04 18:39 ` Eli Zaretskii
2024-07-04 18:48 ` Ihor Radchenko
2024-07-04 13:58 ` Eli Zaretskii
2024-07-04 14:30 ` Gerd Möllmann
2024-07-04 15:43 ` Eli Zaretskii
2024-07-04 15:48 ` Eli Zaretskii
2024-07-04 15:52 ` Pip Cet
2024-07-04 16:04 ` Eli Zaretskii
2024-07-04 17:01 ` Gerd Möllmann
2024-07-04 18:03 ` Eli Zaretskii
2024-07-04 18:28 ` Gerd Möllmann
2024-07-04 18:43 ` Eli Zaretskii
2024-07-04 19:09 ` Gerd Möllmann
2024-07-04 19:12 ` Eli Zaretskii
2024-07-04 16:38 ` Pip Cet
2024-07-04 17:06 ` Gerd Möllmann
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=m28qylcgx1.fsf@pro2.fritz.box \
--to=gerd.moellmann@gmail.com \
--cc=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=pipcet@protonmail.com \
--cc=yantar92@posteo.net \
/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.