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: Wed, 27 May 2020 18:56:17 +0000 Message-ID: References: <83zha8cgpi.fsf@gnu.org> <83r1vibmyj.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> <753eed58-287b-1c47-deef-0e343bca8e69@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="123689"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41321@debbugs.gnu.org, Stefan Monnier To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 27 20:58:10 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 1je1Fg-000Vzo-Jc for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 May 2020 20:58:08 +0200 Original-Received: from localhost ([::1]:53612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1je1Ff-0002ka-L6 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 May 2020 14:58:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je1Fa-0002kN-4y for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 14:58:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38457) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1je1FZ-0005ab-Rj for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 14:58:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1je1FZ-0004IG-QQ for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 14:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 May 2020 18:58: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.159060582316440 (code B ref 41321); Wed, 27 May 2020 18:58:01 +0000 Original-Received: (at 41321) by debbugs.gnu.org; 27 May 2020 18:57:03 +0000 Original-Received: from localhost ([127.0.0.1]:50003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je1Ec-0004H5-Px for submit@debbugs.gnu.org; Wed, 27 May 2020 14:57:03 -0400 Original-Received: from mail-oi1-f178.google.com ([209.85.167.178]:39827) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je1Ea-0004Ga-29 for 41321@debbugs.gnu.org; Wed, 27 May 2020 14:57:01 -0400 Original-Received: by mail-oi1-f178.google.com with SMTP id s198so22688438oie.6 for <41321@debbugs.gnu.org>; Wed, 27 May 2020 11:56:59 -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=Nqml4TW96KHRuCSkWtcZ+rzWfm6RKCwx0rhhFeVghlE=; b=mSw1sC+sN3o5/0ST/czp0xW/QkoNyN9ouydHWr30hLe8hYkVvCaf+wMrqzmwoDdJ+v eVAwXt1HXBWOQAO1n5B0WCmISheLe+A6oTE7WOW0mcCH6AQK+fCPxIbvTGFDF0t8IZuw 36yKRJOuHsGXPrTCypI5mjOJVcoUT2HDluHLLoixAFVuzh7BH52XK7f1NGAZnxQOxFPi f4m0MPUMKVR/lsBByikPD8ycI1RxtmHGTjNDm/Yici/18AvFv6Iu4kCXasWIgQa+q/1i 0x/h7f2IO9/epLqMRXlHMoBkuOHPp//CL6z6YoDvrY/eFSHLrjy+5XdAim8hsPso4tYw cZCw== 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=Nqml4TW96KHRuCSkWtcZ+rzWfm6RKCwx0rhhFeVghlE=; b=Anw7IJucpWE6E03d9Vf/T0bN9MLJekqPgyOQyIrwteanmUQDKZvkZgIsYzJVcjbeWX JyFbG6tbh5R89OxIUMgiRr82ezM/b5FH5hfNxb8M6PslhY4XxD6PMKpSYiRNa7/Ij54Y VSw0Q/nZvRmlOeBLWPVH5k8P8Imz2x/HrS4cKN47IL2iU5A+23rkoDa052hFvO660ila gby6DcgYnVHtjsNiPVBok4Uey5+HWMcxNeXdWyv5svBfOKsjsYNOATKzUe7fs9Qcqjrb VCFwNkhbpMKl8V23HFbrA0tk/WRjS7frpHgkZVO+YcnKK2rbZWdX5pev8Z4Zrk0sYtjY GmvQ== X-Gm-Message-State: AOAM5325hgZVbT08WehqTmg9bMzn6u4ZI6Q+RrpEvLNoB3AkMHfEtal1 MZNzJ0iTNuWWIAyy5WGXpUYqF6kja4oAT7Xc9mY= X-Google-Smtp-Source: ABdhPJwhJ1uIya3BBvmIAisN8zS8iSqx9E7x86v5kv2074DgkO1FRXgTrEydQijHlQ3usyWhyX5XzfIVqi5v6Cc7TmQ= X-Received: by 2002:aca:b708:: with SMTP id h8mr3635896oif.122.1590605814216; Wed, 27 May 2020 11:56:54 -0700 (PDT) In-Reply-To: <753eed58-287b-1c47-deef-0e343bca8e69@cs.ucla.edu> 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:181104 Archived-At: On Wed, May 27, 2020 at 6:39 PM Paul Eggert wrote: > On 5/27/20 10:57 AM, Pip Cet wrote: > > > Do you know of anything like this happening on 64-bit systems? > > I think it's unlikely on 64-bit systems; it'd happen only on platforms where > alignof (void *) < 8, such as x86. > > > Emacs GC does rely, and has always relied since > > GCPRO was removed, on compilers being sensible about what they put on > > the stack. > > This isn't merely an issue about what compilers put into the stack; it's an also > an issue of what's in registers. There may not be any pointer in the stack that > points into the Lisp object. And compilers are not always "sensible" about > temps; they may cache &P->x into a temp with no copy of P anywhere. Or they may cache &P->x + 1, and use negative offsets to access it. That used to be the most efficient way of accessing arrays on some machines. We simply can't cater to that. Think about code like: Lisp_Object reverse(Lisp_Object vector) { ptrdiff_t count = ASIZE (vector); Lisp_Object new_vector = make_nil_vector (count); Lisp_Object *p = aref_addr (vector, count); Lisp_Object *q = new_vector->contents; while (count--) { garbage_collect (); *q++ = *--p; } } (which is what many compilers would generate from more sensible code). On the first iteration, p points to a totally different vector, or some random other object, but it still needs to keep its vector alive. So, at the very least, we need to always keep the immediately preceding object alive if we go that way. > > I'm pretty sure we figured out the crash that Eli observed. It's not > > anything that involved, just a Lisp_Object being stored > > non-consecutively and simultaneously being misaligned for the purposes > > of maybe_lisp_pointer. > > Not sure what the point is here. None of this is "that involved". We can have > pointers into Lisp objects, pointers that are not aligned for the purposes of > maybe_lisp_pointer. Emacs should follow all of them, not just the one that Eli > happened to observe. Or pointers past them, and that's a significant overhead because it usually means two objects are being kept alive by one reference. > > I don't see how you plan to solve it without treating any pointer that > > points even in the vicinity of a valid lisp object as keeping that > > object alive. > Yes, of course. I didn't mean just "within the object", I did mean "in the vicinity". With prefetch instructions, it's quite likely the compiler concludes it's easiest to prefetch something 256 bytes ahead of where it actually makes the access, then make the actual access relative to that address... > Any pointer that points somewhere within a Lisp object (in the C > sense) should count as pointing to the object. The C standard explicitly allows pointers (and that's C pointers) to point one past the end of an allocated array, I believe. > If memory serves, we already > treat pointers that way in some places; unfortunately we're not doing it > consistently. Yes, we do. > But I take your point; I'll post the change here before committing to master. I'm sorry, I misunderstood. If you want to fix only pointers within objects, that is quite a small change, but I believe it is incomplete.