From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects Date: Sat, 30 May 2020 13:29:33 +0000 Message-ID: References: <83zha8cgpi.fsf@gnu.org> <83imgublku.fsf@gnu.org> <831rncjuwf.fsf@gnu.org> <83h7w5xvfa.fsf@gnu.org> <83y2phwb9x.fsf@gnu.org> <83r1v9w9vi.fsf@gnu.org> <83mu5xw50d.fsf@gnu.org> <83k110wxte.fsf@gnu.org> <4bab5f55-95fe-cf34-e490-1d4319728395@cs.ucla.edu> <837dwyvi74.fsf@gnu.org> <1484f569-c260-9fb0-bfe1-67897de289d3@cs.ucla.edu> <83blm9tn4j.fsf@gnu.org> <4aeb8963-4fd1-fcd4-e6e1-be409ab54775@cs.ucla.edu> <83tuzzrk30.fsf@gnu.org> <749bc7d0-6376-ec2e-7f84-dcd3a3cea465@cs.ucla.edu> <83sgfjqn49.fsf@gnu.org> <83eer2m0b6.fsf@gnu.org> <83367hn624.fsf@gnu.org> <831rn1mzgp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0000000000009c4ae205a6dd8fca" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="26236"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 30 15:31:12 2020 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 1jf1Zw-0006n9-5u for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 May 2020 15:31:12 +0200 Original-Received: from localhost ([::1]:52192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jf1Zv-0004EP-5e for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 May 2020 09:31:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jf1Zm-0004By-Fj for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 09:31:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45643) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jf1Zm-0008Qz-5x for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 09:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jf1Zm-0001Qp-2E for bug-gnu-emacs@gnu.org; Sat, 30 May 2020 09:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 May 2020 13:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41321 X-GNU-PR-Package: emacs Original-Received: via spool by 41321-submit@debbugs.gnu.org id=B41321.15908454195449 (code B ref 41321); Sat, 30 May 2020 13:31:01 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 30 May 2020 13:30:19 +0000 Original-Received: from localhost ([127.0.0.1]:57189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf1Z4-0001Pp-TC for submit@debbugs.gnu.org; Sat, 30 May 2020 09:30:19 -0400 Original-Received: from mail-oi1-f176.google.com ([209.85.167.176]:34713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf1Z2-0001Pa-Mc for 41321@debbugs.gnu.org; Sat, 30 May 2020 09:30:17 -0400 Original-Received: by mail-oi1-f176.google.com with SMTP id w4so5195035oia.1 for <41321@debbugs.gnu.org>; Sat, 30 May 2020 06:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EC3o/4T3xhhG+sqFkOFW72c6bqHXbHb1/8OtQDCkBQg=; b=NSDvk3VR4Ez1avPAGZ9peRoIDg2SaXN+/Bl9ZhS5NaM95fpF7PnPPObAJ9M7idDVEk ZrhVurtsA+Ky0vMOg9Up4IgVT64wrxea53uM9zBvvNsrnbGVx5rRtkdegcmLLbhy3riV EYzgsfh2Vz2fULeoYMpVWmwBnMpePU7BqGcd8fJh/ot1Six4rn2hWwX3+zGSNDvjeFE6 vb2XgtJgSmIK70FdWF0LriHb31aYgoeDREZN9hDVfqDaqtRKXHcPYvshK/xjBwAxhALs r5nhVgbeka+hAywVAz0QlyI9QCgc/8gHP8jSS2/rxJzRNsgvPi2gHFAcgd5UN2a8clHO 5Tkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EC3o/4T3xhhG+sqFkOFW72c6bqHXbHb1/8OtQDCkBQg=; b=pVwu4gOtQ9HHmOOZYu6gFOBPCdpEkOXm3/PJkpBIP6qixT4x2670wHEN2TVBRNODje n5lITcnNJWkZ/6/c1BSG9w8wulenSdSBFQU5ijM/XMB0ARkFmsaLHHMqdUtmlT8bX+DL Y7E5Lu7FU6N7Y/lPCzKQzEfAvrV39KJikoLnFf7Kwb1Vvdk9E201qF4rOt1mKMqQRDPE RLwprmY4GOc6pycnpjhcpeyDlRGEsKZGevsxFqrI+0jRfbSmhlpQ9HRz0aPSIqPWSKDC +YZcj8qo+TCZWIVVN2JdOUFltuqUYHLWC7cwRNn/vWjcTDU8KdaMFj8mKevR6Zcwwby2 fZEw== X-Gm-Message-State: AOAM533iFAaugof41tdiR2my378Om0eLrgqpAbKyLRRvxyCkK/dCr8lp O7G93pVjf9uvnaTwcYzMuP+8xUy3Z5XywuvW4CNNeP8X X-Google-Smtp-Source: ABdhPJwsstN6SJYnrBVnYARrhGWQdb7zWE9uPTqdMcMzg5sSngBjS2jvvgBD8Ov40gSAorPGv0iUo+tkpABAVE9W/0U= X-Received: by 2002:aca:b708:: with SMTP id h8mr9088266oif.122.1590845410910; Sat, 30 May 2020 06:30:10 -0700 (PDT) In-Reply-To: <831rn1mzgp.fsf@gnu.org> 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" Xref: news.gmane.io gmane.emacs.bugs:181226 Archived-At: --0000000000009c4ae205a6dd8fca Content-Type: text/plain; charset="UTF-8" On Sat, May 30, 2020 at 11:31 AM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 30 May 2020 11:06:52 +0000 > > Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org, > > Stefan Monnier > > > > > I understand that part, but my question was why, even before the > > > change in max_align_t, did we start requiring 8-byte alignment on > > > systems where that is not automatically guaranteed? > > > > I don't know. As I said, I think that was always buggy on pdumper > > systems, though the bug was very subtle. My guess is it predates > > pdumper, at which time it was a valid optimization. > > How is pdumper involved here? See the pdumper issue I described above. I can't imagine this being a significant bug, because it needs the sole surviving reference to a pdumper object to be on the stack, while simultaneously being the key in a weak-key hash table cell... > > > So this alignment requirement is only due to pthreads being used? > > > > I'm not sure what you're asking. Obviously there are systems on which > > unaligned accesses will fault or be very slow indeed, so we need to > > make sure, say, pure space allocations are aligned somehow. That > > requires a LISP_ALIGNMENT of 8. Everything beyond that is only for > > performance, pthreads, and SIMD types. > > If the system guarantees 4-byte alignment from malloc (and/or a > similar alignment of the runtime C stack), then using that doesn't > trigger problems related to unaligned accesses, right? So let me > rephrase: why isn't 4-byte alignment "good enough" for us on systems > where malloc and the runtime stack are guaranteed to be thus aligned? (The runtime stack isn't relevant, as far as I can tell, since we walk that in 4-byte steps on such systems anyway.) You're correct that on such a system, we could get away with a LISP_ALIGNMENT of 4, but a LISP_ALIGNMENT of 8 wouldn't hurt either. > > > If > > > the two 32-bit parts of the object are non-contiguous, will we be able > > > to recognize such an object, and will we be able to mark it correctly, > > > and if so, how? IOW, don't we need the upper 32-bit (which encodes > > > the object type) for the purposes of marking it? > > > > For everything but symbols, we don't, mark_maybe_pointer called on the > > low 32 bits suffices. For symbols, mark_maybe_pointer needs to be > > changed to also check the pointer at + &lispsym. > > Right, that's what I thought. So this issue also has to be fixed on > emacs-27 in order for us to provide a stable Emacs 27. I'm surprised, but glad that you think so. Patch for emacs-27 attached. --0000000000009c4ae205a6dd8fca Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Be-more-aggressive-in-marking-objects-during-GC-bug-.patch" Content-Disposition: attachment; filename="0001-Be-more-aggressive-in-marking-objects-during-GC-bug-.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kato7yyy0 RnJvbSAzNWQ1MGU2MTA4YzZlZGJhYzkzZTgwYWExYjk5OThkYzZhYzE5MDU0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBTYXQs IDMwIE1heSAyMDIwIDEzOjIzOjI0ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gQmUgbW9yZSBhZ2dy ZXNzaXZlIGluIG1hcmtpbmcgb2JqZWN0cyBkdXJpbmcgR0MgKGJ1ZyM0MTMyMSkKCiogc3JjL2Fs bG9jLmMgKG1heWJlX2xpc3BfcG9pbnRlcik6IFJlbW92ZS4KICAobWFya19tZW1vcnkpOiBNYXJr IDMyLWJpdCB3b3JkcyB0aGF0IG1pZ2h0IGJlIHRoZSBvbmx5IHJlZmVyZW5jZQogIHRvIGEgTGlz cF9TeW1ib2wuCi0tLQogc3JjL2FsbG9jLmMgfCAzNyArKysrKysrKysrKysrKysrLS0tLS0tLS0t LS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTYgaW5zZXJ0aW9ucygrKSwgMjEgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2FsbG9jLmMgYi9zcmMvYWxsb2MuYwppbmRleCAxYzZi NjY0YjIyLi4zOTM4Y2RmMDU0IDEwMDY0NAotLS0gYS9zcmMvYWxsb2MuYworKysgYi9zcmMvYWxs b2MuYwpAQCAtNDU4NSwxOCArNDU4NSw2IEBAIG1hcmtfbWF5YmVfb2JqZWN0cyAoTGlzcF9PYmpl Y3QgY29uc3QgKmFycmF5LCBwdHJkaWZmX3QgbmVsdHMpCiAgICAgbWFya19tYXliZV9vYmplY3Qg KCphcnJheSk7CiB9CiAKLS8qIFJldHVybiB0cnVlIGlmIFAgbWlnaHQgcG9pbnQgdG8gTGlzcCBk YXRhIHRoYXQgY2FuIGJlIGdhcmJhZ2UKLSAgIGNvbGxlY3RlZCwgYW5kIGZhbHNlIG90aGVyd2lz ZSAoaS5lLiwgZmFsc2UgaWYgaXQgaXMgZWFzeSB0byBzZWUKLSAgIHRoYXQgUCBjYW5ub3QgcG9p bnQgdG8gTGlzcCBkYXRhIHRoYXQgY2FuIGJlIGdhcmJhZ2UgY29sbGVjdGVkKS4KLSAgIFN5bWJv bHMgYXJlIGltcGxlbWVudGVkIHZpYSBvZmZzZXRzIG5vdCBwb2ludGVycywgYnV0IHRoZSBvZmZz ZXRzCi0gICBhcmUgYWxzbyBtdWx0aXBsZXMgb2YgTElTUF9BTElHTk1FTlQuICAqLwotCi1zdGF0 aWMgYm9vbAotbWF5YmVfbGlzcF9wb2ludGVyICh2b2lkICpwKQotewotICByZXR1cm4gKHVpbnRw dHJfdCkgcCAlIExJU1BfQUxJR05NRU5UID09IDA7Ci19Ci0KIC8qIElmIFAgcG9pbnRzIHRvIExp c3AgZGF0YSwgbWFyayB0aGF0IGFzIGxpdmUgaWYgaXQgaXNuJ3QgYWxyZWFkeQogICAgbWFya2Vk LiAgKi8KIApAQCAtNDYwOSw5ICs0NTk3LDYgQEAgbWFya19tYXliZV9wb2ludGVyICh2b2lkICpw KQogICBWQUxHUklORF9NQUtFX01FTV9ERUZJTkVEICgmcCwgc2l6ZW9mIChwKSk7CiAjZW5kaWYK IAotICBpZiAoIW1heWJlX2xpc3BfcG9pbnRlciAocCkpCi0gICAgcmV0dXJuOwotCiAgIGlmIChw ZHVtcGVyX29iamVjdF9wIChwKSkKICAgICB7CiAgICAgICBpbnQgdHlwZSA9IHBkdW1wZXJfZmlu ZF9vYmplY3RfdHlwZSAocCk7CkBAIC00NzE1LDEyICs0NzAwLDIyIEBAIG1hcmtfbWVtb3J5ICh2 b2lkIGNvbnN0ICpzdGFydCwgdm9pZCBjb25zdCAqZW5kKQogCiAgIGZvciAocHAgPSBzdGFydDsg KHZvaWQgY29uc3QgKikgcHAgPCBlbmQ7IHBwICs9IEdDX1BPSU5URVJfQUxJR05NRU5UKQogICAg IHsKLSAgICAgIG1hcmtfbWF5YmVfcG9pbnRlciAoKih2b2lkICpjb25zdCAqKSBwcCk7Ci0KLSAg ICAgIHZlcmlmeSAoYWxpZ25vZiAoTGlzcF9PYmplY3QpICUgR0NfUE9JTlRFUl9BTElHTk1FTlQg PT0gMCk7Ci0gICAgICBpZiAoYWxpZ25vZiAoTGlzcF9PYmplY3QpID09IEdDX1BPSU5URVJfQUxJ R05NRU5UCi0JICB8fCAodWludHB0cl90KSBwcCAlIGFsaWdub2YgKExpc3BfT2JqZWN0KSA9PSAw KQotCW1hcmtfbWF5YmVfb2JqZWN0ICgqKExpc3BfT2JqZWN0IGNvbnN0ICopIHBwKTsKKyAgICAg IHVpbnRwdHJfdCBvZmZzZXQgPSAodWludHB0cl90KSAqKHZvaWQgKmNvbnN0ICopIHBwOworICAg ICAgbWFya19tYXliZV9wb2ludGVyICgodm9pZCAqKSBvZmZzZXQpOworICAgICAgLyogT24gMzIt Yml0IC0td2l0aC13aWRlLWludCBzeXN0ZW1zLCB0aGUgdHdvIGhhbHZlcyBvZiBhCisJIExpc3Bf T2JqZWN0IG1heSBiZSBzdG9yZWQgbm9uLWNvbnRpZ3VvdXNseS4gIFRoZXJlZm9yZSwgd2UKKwkg bmVlZCB0byByZWNvZ25pemUgdGhlIGxvd2VyIDMyIGJpdHMgb2YgYSBMaXNwX09iamVjdCBlbmNv ZGluZworCSBhIHN5bWJvbCwgYW5kIHNpbmNlIFFuaWwgaXMgYmluYXJ5IHplcm8sIHRoYXQgcmVx dWlyZXMgYWRkaW5nCisJICZsaXNwc3ltLiAgKi8KKyAgICAgIGlmIChHQ19QT0lOVEVSX0FMSUdO TUVOVCA8IHNpemVvZiAoTGlzcF9PYmplY3QpKQorCW1hcmtfbWF5YmVfcG9pbnRlciAoKHZvaWQg KikgKG9mZnNldCArICh1aW50cHRyX3QpICZsaXNwc3ltKSk7CisgICAgICBlbHNlCisJeworCSAg dmVyaWZ5IChhbGlnbm9mIChMaXNwX09iamVjdCkgJSBHQ19QT0lOVEVSX0FMSUdOTUVOVCA9PSAw KTsKKwkgIGlmIChhbGlnbm9mIChMaXNwX09iamVjdCkgPT0gR0NfUE9JTlRFUl9BTElHTk1FTlQK KwkgICAgICB8fCAodWludHB0cl90KSBwcCAlIGFsaWdub2YgKExpc3BfT2JqZWN0KSA9PSAwKQor CSAgICBtYXJrX21heWJlX29iamVjdCAoKihMaXNwX09iamVjdCBjb25zdCAqKSBwcCk7CisJfQog ICAgIH0KIH0KIAotLSAKMi4yNy4wLnJjMAoK --0000000000009c4ae205a6dd8fca--