From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: MPS: assertion failed: header_type (h) != IGC_OBJ_FWD Date: Wed, 17 Jul 2024 03:51:40 -0400 Message-ID: References: <86zfqhh2xv.fsf@gnu.org> <87msmhwhal.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15732"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , Helmut Eller , Eli Zaretskii , Paul Eggert , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 17 09:52:24 2024 Return-path: Envelope-to: ged-emacs-devel@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 1sTzSZ-0003o6-9d for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Jul 2024 09:52:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sTzRv-0002m4-Vb; Wed, 17 Jul 2024 03:51:43 -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 1sTzRu-0002lp-Gn for emacs-devel@gnu.org; Wed, 17 Jul 2024 03:51:42 -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 1sTzRt-0001DF-HB; Wed, 17 Jul 2024 03:51:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=bu4b/7RAsCWDXmLTz86P2raY5NlmfpPPA5cf+Zrsp54=; b=WgQvp/tu+uY+7RBlM51Z tjvTlBf+WIIHA++aI+fj1im6qZg1YwzZnKjGHJ7gyOabwbmKYLKR9la2ANTUjoROQGStYeMSsIbz7 7k0XMlipSJ7eaTksW4Xm0Ys510ITHSR9ohfFVSfqMdUmOfKQdtmle5vy06NJoNdotmi4PleflPmd1 w8vmd1gju5wVQxxI+yXVftE3USW35Q0YQRAKVhl6ldhIBOWeE+WkHKyW34MbLc8pbDF82OIO1K0k1 3nJKEH0b4EzFbIbPOLePB4zEri4FLcgegAhQbSy5rBlcUTpr+ighgmPTBe8q92sGWrFBOHFnNzk8x o1fPm0fThkY4rA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sTzRs-0001Zh-ID; Wed, 17 Jul 2024 03:51:40 -0400 In-Reply-To: (Pip Cet's message of "Tue, 16 Jul 2024 16:13:23 +0000") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321743 Archived-At: Pip Cet writes: > On Tuesday, July 16th, 2024 at 14:48, Gerd M=C3=B6llmann wrote: >> Helmut Eller eller.helmut@gmail.com writes: >>=20 >> > On Tue, Jul 16 2024, Gerd M=C3=B6llmann wrote: >> >=20 >> > > That's probably a misunderstanding. I'm thinking about a block of me= mory >> > > containing references, and the alignment of these references, not the >> > > alignment of the block. >> > >=20 >> > > Example with sizeof(int) =3D 4, and sizeof(void *) =3D 8 >> > >=20 >> > > struct x >> > > { >> > > int x; >> > > struct Lisp_Symbol *s; >> > > }; >> > >=20 >> > > What about the offset of x::s? >> >=20 >> > That's not a problem because offsetof(struct x, s) =3D 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. >>=20 >>=20 >> 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 wron= g_type_argument helpful, since we usually hit that when memory moves and th= e old pointer doesn't point to an object of the right type. > > By the way, I'm done with the code for making base =3D=3D 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