From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: STatus of MPS branch Date: Sun, 21 Apr 2024 22:24:05 +0200 Message-ID: <87ttjulb16.fsf@gmail.com> References: <878r16n5jl.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="17589"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 21 22:25:17 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 1rydkS-0004P5-N0 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Apr 2024 22:25:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rydje-0006uu-CG; Sun, 21 Apr 2024 16:24:26 -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 1rydjc-0006ui-Gl for emacs-devel@gnu.org; Sun, 21 Apr 2024 16:24:24 -0400 Original-Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rydjV-0002ks-Nl for emacs-devel@gnu.org; Sun, 21 Apr 2024 16:24:24 -0400 Original-Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-571bddddbc2so3242325a12.1 for ; Sun, 21 Apr 2024 13:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713731047; x=1714335847; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=BP4tmS2vM5A2UPaoMGYmZkTmEdr5/AjCkj5ODDr7gjM=; b=S5jXbk00m+orio63VBIja3yUmmBH4cvxWUbCn72LQTveS0rTkUjgLkOFm7h4BJC/QY eX0jzblplJ8xfPPFWZzdZK5vAscdSEuxCy3Vbdb3TdmC+/zyB1YZ8kbBnmS0VXgIO88Q szRnQajlJ7suArWUM0GQlaGwbC2oOgsOl8aTIzmZAtUtivCIWlXwKGH0r2OffTrVp4dw lbdMxdpveeIWe6jJzxNoSAk8V29yXOkgjPiXbg+n6fmSuzdo+3Xzsdudg0ASxQ7A/5lZ IaTvylYniSm9Vgv4BQBqIFg9zrPzu3sMFmITAk02atBtpNOz/NDh3ZjXoI9i02+QtDQE sDuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713731047; x=1714335847; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BP4tmS2vM5A2UPaoMGYmZkTmEdr5/AjCkj5ODDr7gjM=; b=sUtZXHck8w4V2jCgdMDbgec2yo8wp+QHidWDzZWVi5BtO7VQhI1BkYz1MLEICei+W/ Snicj1uvZzrpuuF4rzAdZsH8H3eeEvn/a1fLjQFwFkSzuYMoPN5ecKXlPUw3duy6nNJJ oTgOWs6O8UZF/yvK1O0SW5UObW5YNwLNhi0GM6PP6tISmwobeemC8vmMGHXhiBnmY4oB XmqNT4Cmg7ueol/e19STJjU0Hwht8uPX+4Mgxx6xsvEKQgqfzawoZKtyDhrmNlnJk6sQ RwlDNw/FLb9up13dmTB5XYt/bpK3uftrc4vLRc2tbnuSAStTFEzSE9HS0fch5Zi1+QXl pUUw== X-Gm-Message-State: AOJu0YzvFJf3cZB8yN7lhgGFw6k9zCBI2Qgf3SJD9PsDnlSh+evW3/gM bk4BpGd4fIbBaVvJY+MEaH9KS60TNi4gfDa1zoELAosmQN/L553ApOdn+g== X-Google-Smtp-Source: AGHT+IGMtEBKWJ5tJXgmpiEzzviM+xFPfEZ4LsGZUjys+kNFWZa93pvtyR7OXE4lm5ikWuCcbffefQ== X-Received: by 2002:a50:d60c:0:b0:56f:e609:743 with SMTP id x12-20020a50d60c000000b0056fe6090743mr5300556edi.35.1713731046751; Sun, 21 Apr 2024 13:24:06 -0700 (PDT) Original-Received: from caladan ([89.107.106.118]) by smtp.gmail.com with ESMTPSA id o16-20020aa7d3d0000000b0057046dc6a1fsm4701358edr.25.2024.04.21.13.24.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Apr 2024 13:24:06 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann?= =?utf-8?Q?=22's?= message of "Sun, 21 Apr 2024 17:37:09 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=eller.helmut@gmail.com; helo=mail-ed1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:317938 Archived-At: On Sun, Apr 21 2024, Gerd M=C3=B6llmann wrote: [..] >> igc.c:229:18: warning: =E2=80=98pvec_type=E2=80=99 is narrower than valu= es of its type >> 229 | enum pvec_type pvec_type : IGC_PVEC_BITS; > > Good catch, clang didn't find that. You could increase the bit field > size by 1, and the one for the hash by 1, for example. I did this; GCC stopped complaining but otherwise it made no observable difference. [..] >> # define igc_assert(expr) \ >> if (!(expr)) \ >> igc_assert_fail (__FILE__, __LINE__, #expr); \ >> - else >> + /* else */ [..] > Don't know, this looks a bit problemantic, but if it's the problem I > don't know. Removing the else means something like > > if (x) > igc_assert (...); > else > do something else > > expand to something one doesn't want. The else is swallowed by the if in > the macro... Without some change GCC emits lots of warnings of this kind: igc.c: In function =E2=80=98to_words=E2=80=99: igc.c:246:49: warning: suggest braces around empty body in an =E2=80=98else= =E2=80=99 statement [-Wempty-body] 246 | igc_assert (nbytes % sizeof (mps_word_t) =3D=3D 0); | ^ So maybe the macro should end with "else {}". [..] >> static mps_res_t >> fix_image (mps_ss_t ss, struct image *i) >> { >> +#ifdef HAVE_WINDOW_SYSTEM >> MPS_SCAN_BEGIN (ss) >> { >> IGC_FIX12_OBJ (ss, &i->spec); >> @@ -964,6 +966,7 @@ fix_image (mps_ss_t ss, struct image *i) >> } >> MPS_SCAN_END (ss); >> return MPS_RES_OK; >> +#endif >> } > > If I'm reading this one right, the function doesn't return a value. > But maybe this doesn't get compiled? Yes. it's just to get it compiled; struct image isn't defined with my config. >> INFO Scraping files for loaddefs...80%=20 >> >> Program received signal SIGSEGV, Segmentation fault. >> >> Breakpoint 1, handle_sigsegv (sig=3D11,=20 >> siginfo=3D0x555555f6ed70 ,=20 >> arg=3D0x555555f6ec40 ) at sysdep.c:1930 >> 1930 bool fatal =3D gc_in_progress; >> (gdb) backtrace=20 >> #0 handle_sigsegv (sig=3D11, siginfo=3D0x555555f6ed70 ,=20 >> arg=3D0x555555f6ec40 ) at sysdep.c:1930 >> #1 >> #2 string_intervals (s=3DXIL(0x7ffff0698edc)) >> at /scratch/emacs/emacs-igc/src/lisp.h:4063 >> #3 0x0000555555767d97 in concat_to_string (nargs=3D3, args=3D0x7fffe5f0= 35b8) >> at fns.c:957 > > I think I'd start in #2 here, by looking at S. First question would be > if the string itself it ok, and what kind of string it is. I haven't > used GDB with Emacs here for a very long time (no GDB on macOS), so I'm > a bit out of my comfort zone. > > # We need the pointer to the Lisp_String that's in S, let's say it's P. > # Don't know how, sorry > ??? I changed some things and now I can no longer reproduce the exact same problem. But it looked to me like a perfectly normal string with intervals=3D0x0. Strangely, accessing the intervals field from GDB didn't cause any SIGSEGV. However, after setting breakpoints in handle_sigsegv and sigHandle (from MPS) I discovered that sigHandle wasn't called. So my hypothesis is that the signal handler isn't initialized properly. In particular, it seems problematic that ProtSetup (from MPS) is called before init_signals. Then I moved the call to init_signals in emacs.c up before the call to init_igc and voil=C3=A0: the build completed. With an apparently working (tty-only) Emacs. Helmut