From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: STatus of MPS branch Date: Sun, 21 Apr 2024 17:37:09 +0200 Message-ID: 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="32644"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 21 17:38:05 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 1ryZGW-0008Ja-RV for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Apr 2024 17:38:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryZFl-0004xS-QD; Sun, 21 Apr 2024 11:37:17 -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 1ryZFl-0004xE-21 for emacs-devel@gnu.org; Sun, 21 Apr 2024 11:37:17 -0400 Original-Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ryZFj-0006ek-8M for emacs-devel@gnu.org; Sun, 21 Apr 2024 11:37:16 -0400 Original-Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a519e1b0e2dso398276466b.2 for ; Sun, 21 Apr 2024 08:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713713832; x=1714318632; 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=HbxSpy2bL3eaHaqXdyta3Lsa/mVDlm2tRh1lTqnkN3w=; b=nmXNbVhaj6UWVASKqMQLdUB8DquO3kt9xsvUI5uRgqYwK2gDJvVobWq1cSuc1S1D+P BYV5rZDSI5TI3OkCxwlC74MS4Ov1OsTcmaFxXBsEf4h1vN2ozSZSoVPSjYtnlJNMPgyS f+DjW7RZamEsEdVNoKVF4wl4qqwEYrVN5gl49EWlj2cQ6rhB9YX6g9K7u/ydJqxbhTud z0jZzznkCrjzhk6HDk4Fz3gYPbJW5Wc3L4RU+onpIiOlEKkRLsSu/ch+2JLsvXDKeZ5l szaJ0w3np/72dSm628wEn0tUMjourvOjU85BuuKYwgwjAJm8s1f2ikDcKuczLP5K/UJx o/Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713713832; x=1714318632; 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=HbxSpy2bL3eaHaqXdyta3Lsa/mVDlm2tRh1lTqnkN3w=; b=ICCEnR3+Fs0Fd/E3W/uV8lGLd35nGA8vIixrbkwO2yr7iNCzVZeZ8pLp7T2d+CucR/ BX/0buUfYLnCuziLx3BMGx+VY0iSzWnJ4jdEWfWglBi/OBWCt/dRm16kxp5L95YRs/XM YHZsmWJXvYEl+urJWr4iQI8ZEryRUvXswqejRMF+i0vj1luTAoMNGpaieq0Amif+8WAs az8dGEgutpcabWLaIo/xpOe/OxeJnNpb90z1FT1qTUGKE0mPaphg0qq/AE87obVAX33D f6G979gm8uof6ELvXAS4cdlbLE/BFC9HxijoDOKcz7PgNjmlGxkwO0FGXJ2Sglo30YVy NpXQ== X-Gm-Message-State: AOJu0YyIonC3OMo2/mcrLQ6/q1UfmS0HEdiXFGTmh5sST2P3I73zKrCC iYY/mvIuYeNBryOEZUCBWl9KjCNkrjaoyeaB11dtg5RIWF511Ejwi8EocsQE X-Google-Smtp-Source: AGHT+IGUGP737PnC0HjEIiGDl9ylFhxHEOCpnhIQMhbWc3cXUiLqyPa2Fag9H1UYaNX3jM4m9kg1Xg== X-Received: by 2002:a17:907:6d0d:b0:a55:ae3c:85da with SMTP id sa13-20020a1709076d0d00b00a55ae3c85damr1577310ejc.15.1713713831924; Sun, 21 Apr 2024 08:37:11 -0700 (PDT) Original-Received: from Pro.fritz.box (pd9e36945.dip0.t-ipconnect.de. [217.227.105.69]) by smtp.gmail.com with ESMTPSA id gr17-20020a170906e2d100b00a52277726b3sm4615241ejb.201.2024.04.21.08.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Apr 2024 08:37:11 -0700 (PDT) In-Reply-To: <878r16n5jl.fsf@gmail.com> (Helmut Eller's message of "Sun, 21 Apr 2024 16:39:42 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x633.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:317936 Archived-At: Helmut Eller writes: > On Sat, Apr 20 2024, Gerd M=C3=B6llmann wrote: > >> There are many things other people could help with at this point. Some >> require no knowledge of MPS, or C. For example: >> >> - Make it work on anything not macOS. > > I'm trying to build the igc branch on Debian. But I get a SIGSEGV when > loaddefs-gen.el gets loaded. > > I configured with: > CFLAGS=3D'-g -O0 -I/scratch/emacs/mps-install/include -L/scratch/emacs/= mps-install/lib' configure --enable-checking=3Dyes --without-all --without-= x --with-mps=3Ddebug > > and made some changes to igc.c as seen in the diff below; but those seem > rather innocent. > > GCC still emits this warning: > > igc.c:229:18: warning: =E2=80=98pvec_type=E2=80=99 is narrower than value= s of its type > 229 | enum pvec_type pvec_type : IGC_PVEC_BITS; Hi Helmut! 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. > Is this something to worry about? I don't think so. I'm using the pvec_type for debugging, mainly. > > Helmut > > diff --git a/src/igc.c b/src/igc.c > @@ -81,7 +81,7 @@ igc_assert_fail (const char *file, unsigned line, const= char *msg) > # define igc_assert(expr) \ > if (!(expr)) \ > igc_assert_fail (__FILE__, __LINE__, #expr); \ > - else > + /* else */ > #else > # define igc_assert(expr) (void) 9 > #endif > @@ -122,7 +122,7 @@ is_aligned (const mps_addr_t addr) > #define IGC_CHECK_RES(res) \ > if ((res) !=3D MPS_RES_OK) \ > emacs_abort (); \ > - 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... > #define IGC_WITH_PARKED(gc) \ > for (int i =3D (mps_arena_park (gc->arena), 1); i; \ > @@ -801,6 +801,7 @@ scan_pure (mps_ss_t ss, void *start, void *end, void = *closure) > MPS_SCAN_BEGIN (ss) > { > igc_assert (start =3D=3D (void *) pure); > + extern ptrdiff_t pure_bytes_used_lisp; > end =3D (char *) pure + pure_bytes_used_lisp; > if (end > start) > IGC_FIX_CALL (ss, scan_ambig (ss, start, end, NULL)); > @@ -954,6 +955,7 @@ fix_itree_node (mps_ss_t ss, struct itree_node *n) > 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? Otherwise, I don't see something suspicious. > 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=3D0x7fffe5f03= 5b8) > 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 ??? # Is P in the dump? p pdumper_object_p (P)=20 # Is P potentially under MPS control? p is_mps (P) # If it is, what does its header look like (assuming 64 bit words) p *(struct igc_header *) ((char *) P - 8) And then, in general, we would need to know where that string comes from. It could for example be that the string has been free'd by MPS because it didn't see a reference to it. That's admittedly not entirely easy. It memans going up the stack, and look around, maybe infering from the Lisp backtrace what Emacs was trying to do, and such.