emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: assertion failed: header_type (h) != IGC_OBJ_FWD


From: Andrea Corallo
Subject: Re: MPS: assertion failed: header_type (h) != IGC_OBJ_FWD
Date: Wed, 17 Jul 2024 03:51:40 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]