all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: Pip Cet <pipcet@protonmail.com>
Cc: "Gerd Möllmann" <gerd.moellmann@gmail.com>,
	"Helmut Eller" <eller.helmut@gmail.com>,
	"Eli Zaretskii" <eliz@gnu.org>,
	"Paul Eggert" <eggert@cs.ucla.edu>,
	emacs-devel@gnu.org
Subject: Re: MPS: assertion failed: header_type (h) != IGC_OBJ_FWD
Date: Wed, 17 Jul 2024 03:51:40 -0400	[thread overview]
Message-ID: <yp1y160a22b.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <SPhZN-UkyU9p1Fhv85uuOk-OVGUhi452rnmb6t4sh_j2jMdxA-RO_e7r_l_4uIxKvTa86thH2xepz_pyrdGXxzNnchgYoirpWZ82-P14bnQ=@protonmail.com> (Pip Cet's message of "Tue, 16 Jul 2024 16:13:23 +0000")

Pip Cet <pipcet@protonmail.com> writes:

> On Tuesday, July 16th, 2024 at 14:48, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>> Helmut Eller eller.helmut@gmail.com writes:
>> 
>> > On Tue, Jul 16 2024, Gerd Möllmann wrote:
>> > 
>> > > That's probably a misunderstanding. I'm thinking about a block of memory
>> > > containing references, and the alignment of these references, not the
>> > > alignment of the block.
>> > > 
>> > > Example with sizeof(int) = 4, and sizeof(void *) = 8
>> > > 
>> > > struct x
>> > > {
>> > > int x;
>> > > struct Lisp_Symbol *s;
>> > > };
>> > > 
>> > > What about the offset of x::s?
>> > 
>> > That's not a problem because offsetof(struct x, s) = 8. There are 4
>> > bytes padding after x. A problem could be if an unaligned void* is cast
>> > to a struct Lisp_Symbol*; let's hope that nobody does that.
>> 
>> 
>> If you're right, and the same holds for the control stack and anything
>> else a malloc'd block can contain, then we're safe.
>
> I'm pretty sure we are, though interior pointers might cause a problem.
>
> Any leads on where the crash happens yet? I've found a breakpoint on wrong_type_argument helpful, since we usually hit that when memory moves and the old pointer doesn't point to an object of the right type.
>
> By the way, I'm done with the code for making base == client pointers
> and giving (almost) every object a header. Since it's a major change
> and can't really be split that well, I'm not sure yet how to install
> it, though it needs to be cleaned up still in any case... But when I
> do install it, it will require rebuilding of all .eln files, or there
> will be weird segfaults. (I guess we could bump the ABI constant in
> the nativecomp code to avoid that).

Yep, I confirm updating ABI_VERSION is the right thing to do in order to
be sure we don't use stale elns when an incompatible change is made.

  Andrea



  parent reply	other threads:[~2024-07-17  7:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-14  4:12 MPS: assertion failed: header_type (h) != IGC_OBJ_FWD Gerd Möllmann
2024-07-14  5:30 ` Pip Cet
2024-07-14  7:00   ` Gerd Möllmann
2024-07-14  7:08     ` Gerd Möllmann
2024-07-16 13:02     ` Gerd Möllmann
2024-07-16 13:38       ` Eli Zaretskii
2024-07-16 13:47         ` Gerd Möllmann
2024-07-16 14:11           ` Eli Zaretskii
2024-07-16 14:39             ` Gerd Möllmann
2024-07-16 15:21               ` Eli Zaretskii
2024-07-16 16:54                 ` Gerd Möllmann
2024-07-16 14:19           ` Helmut Eller
2024-07-16 14:48             ` Gerd Möllmann
2024-07-16 15:22               ` Eli Zaretskii
2024-07-16 16:13               ` Pip Cet
2024-07-16 16:47                 ` Gerd Möllmann
2024-07-17  7:51                 ` Andrea Corallo [this message]
2024-07-17 19:47               ` Gerd Möllmann
2024-07-18 15:08                 ` Gerd Möllmann
2024-07-18 16:05                   ` Pip Cet
2024-07-18 16:33                     ` Gerd Möllmann
2024-07-18 19:06                   ` Andrea Corallo
2024-07-18 19:33                     ` Gerd Möllmann
2024-07-19  4:38                       ` Gerd Möllmann
2024-07-23  0:36                         ` Pip Cet
2024-07-23  3:31                           ` Gerd Möllmann
2024-07-16 15:49         ` Paul Eggert

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=yp1y160a22b.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=eller.helmut@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=pipcet@protonmail.com \
    /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.