From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#74966: 31.0.50; Crash report (using igc on macOS) Date: Sat, 21 Dec 2024 08:08:40 +0100 Message-ID: References: <86a5cqkc2g.fsf@gnu.org> <86o716ah09.fsf@gnu.org> <87ikrejok5.fsf@protonmail.com> <86cyhm9m9a.fsf@gnu.org> <87seqihyex.fsf@protonmail.com> <864j2xa5x0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28301"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: spd@toadstyle.org, Pip Cet , acorallo@gnu.org, monnier@iro.umontreal.ca, 74966@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 21 08:10:26 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tOtd4-0007Ch-46 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Dec 2024 08:10:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOtci-0004XX-BK; Sat, 21 Dec 2024 02:10:04 -0500 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 1tOtcg-0004XD-ND for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2024 02:10:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOtcg-000116-E1 for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2024 02:10:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=9/k/9uleCSdhX/31pYPvnCz5RZwjQhcpK0r1Wxm5AOQ=; b=QSax6znKNOf7p1joXL78DsDW3R0PAUTnwI8rROrX20PMH9yizEGGXqyb7uIWc6KvcQ2Xn11jvm3cNO1HtgwBTdhlPOYrXGUBWMpwP4sesYICZv+yG8IeeMiKraE75xOTkN5xhyqwb4EQyhBwXrbutgsQvRgHv+k5WBFg+02VTxn6HwP8syYSIifUBm+ZCGN3TkXfQjHzb5NBGMZY09TYt/CN+KvfuzzVOYqrCd3Rv48+7FyOYk2EaXMYFLaiUx25deLMjiAzHXfJ95HCLSX+QaMl0m90sOWNw16SnX5njhBYauyeS9QCq/EvV4d/7IjAPCez0ozjmgigZnYfmWm65Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tOtcg-0000Vv-4e for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2024 02:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Dec 2024 07:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74966 X-GNU-PR-Package: emacs Original-Received: via spool by 74966-submit@debbugs.gnu.org id=B74966.17347649871938 (code B ref 74966); Sat, 21 Dec 2024 07:10:02 +0000 Original-Received: (at 74966) by debbugs.gnu.org; 21 Dec 2024 07:09:47 +0000 Original-Received: from localhost ([127.0.0.1]:45022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tOtcR-0000VC-0M for submit@debbugs.gnu.org; Sat, 21 Dec 2024 02:09:47 -0500 Original-Received: from mail-ed1-f42.google.com ([209.85.208.42]:49232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tOtcO-0000V3-Eb for 74966@debbugs.gnu.org; Sat, 21 Dec 2024 02:09:45 -0500 Original-Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5d27243ba8bso4892204a12.2 for <74966@debbugs.gnu.org>; Fri, 20 Dec 2024 23:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734764923; x=1735369723; darn=debbugs.gnu.org; h=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=9/k/9uleCSdhX/31pYPvnCz5RZwjQhcpK0r1Wxm5AOQ=; b=IUkPKuLj2kFjL0ug9JbA1HOGcG2UrO5ocweaduaoGjYW6XvkonZehZ9zypXk6au6kI 9+Ppq/4CJ60B6HA1K7/jbw2VjapqWlTGK74St+30IQyilzHkbwDJsQMCY2Jc6QNbKlrh 8hzvSgn3hWHCyjd11Fc76HYEY0P0s123NRjsF/XXhnwn2MogdCdchhy/ZU4wJvXr5ShW nfkvuF1vqLnOn0jnpkk6A8CEXU4GRksTDM5Xm8UTzftXKs1JRgMnmJ/Yg61yqmTyuxwP yxlS6YZNkYXZMHlGH0yhHOYInyZGC1U/GUs7gG+uiebJbR5052Ta0vcCW3rw+GUwEjdA ZFwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734764923; x=1735369723; h=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=9/k/9uleCSdhX/31pYPvnCz5RZwjQhcpK0r1Wxm5AOQ=; b=rPp/iJySkAk+XK48gh73/DrG8anbZFq2vCzvXJGJEzmumy1P8QWdg4MO61Qh0lJC/u bIXjSsBZg2gb0GJbr9pbpDuGHVGf7FpRQXo8c7BkZfz4dLlUbOGAmcCZGFNoCq8TIbGi pU8lbbzMQg/jFRFCYxT8qkwCwM2QTLOEi7V+C7sM4tmLUNedCZ1iRnqaIiGoUBQBszuq L7nzRhW20IlVeOLc/ULEur7uPYXxo7PqMiW75K+TVIwrW6mRsq69QjV1RaDYmey1FYsX 2oJRQajidtFN6HdxTYftgqnteobeLcx6bjrve5fuWaNnNcVxIBJvSKZ54G91m3b63d+A UPlg== X-Forwarded-Encrypted: i=1; AJvYcCXRFTHAdhIGCzBVCJCR07n2Azn17pQVx/f2tMJAZaC2wheYDBAeLZ6cfrkT2bEY7H931gUzNA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwvrVikPNuBNZs/qvtFpE1j9FbKhLjXlJ3pL4qgrzBrSHv/9IhA ORrp9oR1Afvzuo581kRKwi8fN9MZF61jXe+sh4g/5e5i7t/FcRsqi92+6g== X-Gm-Gg: ASbGnctkNmB77x3qSyVnycivN9XvWJunM5F12/ypDAK7cJvt4B3dQ9euhvHSRghs355 52lmFYk0F6o60s59wm19ehpSlSIMSIGBKBIb2fkMjQGwlpoOEhxbctfOTHLs9skhPeS5wAJCx6u GSN1QgaOi5wtwBaL+0T9Xoa4GVW5NZLpWUCP2SqBgQMfGpNKA5d6O6Jw7XTZ+o7bX63hdwXif6K bCbbzGscijkO3DMBY8pzPpPXl9isc9LKccqt49KO70a1PyBgGrXwX9Jn0yOQQXhVrPAxXwfa36x eYAHbN1wYqAMB06iCz/Pxw2uk5r9jVm3RH9u6QWqyXXHK1NtjQ80P5jVFYu70ozyJw== X-Google-Smtp-Source: AGHT+IH9JuYk7USy+1v7ol+6vT/JtTZtkfy1kfrxESdVW6RVOUWRoHLVZO/+5rp8AFwgHtLDUm6Maw== X-Received: by 2002:a17:907:7e9d:b0:aa6:88c6:9449 with SMTP id a640c23a62f3a-aac2ad863camr470126866b.19.1734764922926; Fri, 20 Dec 2024 23:08:42 -0800 (PST) Original-Received: from pro2 (p200300e0b7162300456cde412cc45ae9.dip0.t-ipconnect.de. [2003:e0:b716:2300:456c:de41:2cc4:5ae9]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80675a735sm2422573a12.10.2024.12.20.23.08.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2024 23:08:41 -0800 (PST) In-Reply-To: <864j2xa5x0.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Dec 2024 08:47:39 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297487 Archived-At: Eli Zaretskii writes: >> Date: Fri, 20 Dec 2024 20:50:56 +0000 >> From: Pip Cet >> Cc: gerd.moellmann@gmail.com, spd@toadstyle.org, acorallo@gnu.org, monnier@iro.umontreal.ca, 74966@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> > TBH, I'd be much happier without splitting 'doc' into two members. >> > Isn't it possible to avoid overwriting 'doc', thus avoiding the crash, >> > without splitting the member in two? >> >> Absolutely. That'd cause wrong docstrings for some symbols > > Can you elaborate on that? When and how could that happen? > >> but reduce >> the risk of code not compiling anymore. There is no risk of unvetted >> code compiling and accessing the doc field, because it's been renamed, >> but that does require, of course, to consider the changes in the patch >> as "vetted"; furthermore, if there is a compilation error in some code >> I've missed, we need to be careful not to fix it without checking that >> code, too. > > I didn't have in mind problems that will be caught by the compiler -- > these are easy to find and fix, even if it takes some time because > some code is only compiled on a certain rarely-used platform or > configuration. > >> > DOC handling in Emacs is extremely complex and has many subtle >> > aspects. Experience teaches us that bugs in this area sometimes take >> > years to report and fix. Splitting a member into two risks >> > introducing bugs because we might use the wrong member in some >> > situation(s). >> >> I don't understand this specific objection. If we rename "doc" to >> "doc_offset", as I've proposed, we're automatically looking at all code >> which makes use of the new field, because code using the old name no >> longer compiles. > > Yes, sure. If we just rename a single member and all of its > references, there's no risk whatsoever. I had something else in mind. > If we split the 'doc' member in two, some code which used 'doc' will > need to use 'doc_index', and some code will need to use 'doc_offset'. > The risk is in using the wrong one, because the intent of the original > code (i.e., whether it interprets 'doc' as an index or as an offset) > was not completely understood. Moreover, it is possible that in some > places we'd need to set the value of one of these two members from the > value of the other, because the original code relied on the fact that > there's just one member whose value is sometimes interpreted as this > and sometimes as that. > >> > The test suite's coverage of doc.c and features related >> > to doc strings is still rudimentary, so we cannot be sure any such >> > bugs will be caught in time by the tests. Which is why I hope we can >> > avoid splitting this member in two. >> >> I agree that the docfile hack in general is very hairy territory. It >> might be safer to simply accept the wrong docstrings for now, and Gerd's >> patch does that, IIUC. Can we just apply that for now and add a FIXME? > > Maybe, but I'd like first to understand better the "wrong docstrings" > situations. Maybe I can explain this. The current error's cause is that nativecomp currently (wrongly) assumes that it never needs an offset into DOC, so it reused Lisp_Subr::doc for its own purposes, namely as an index into a vector contained in an .eln file. The doc string of a function is found at that index. Pip's patch changes nativecomp code stores the said index from above in a new Lisp_Subr::doc_index, and makes it possible to fix the wrong assumption from above, Nativecomp of course has to check which of the now two members it has to use, which Pip does. Renaming Lisp_Subr::doc to Lisp_Object::doc_offset is a nice extra, IMO, because it makes it clearer what the member contains.