From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Mon, 8 Mar 2021 14:50:50 +0000 Message-ID: References: <86eehujcip.fsf@gmail.com> <86blch14qt.fsf@gmail.com> <83h7m84h9g.fsf@gnu.org> <86v9ao5czu.fsf@gmail.com> <86wnutogrh.fsf@gmail.com> <86wnut8fb9.fsf@gmail.com> <861rd1tbpa.fsf@gmail.com> <83pn0km6y3.fsf@gnu.org> <86ft1f8ara.fsf@gmail.com> <83sg5cjdn8.fsf@gnu.org> <83r1kwjcy2.fsf@gnu.org> <8335x6u9o4.fsf@gnu.org> <83zgzesrku.fsf@gnu.org> <83r1kpsrng.fsf@gnu.org> <83blbtso9k.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39929"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com, Andrea Corallo To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 08 15:52:10 2021 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 1lJHEv-000AE2-UT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 15:52:10 +0100 Original-Received: from localhost ([::1]:46542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJHEv-0003I4-0U for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 09:52:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJHEo-0003Hb-5U for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 09:52:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59189) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJHEn-0002ys-V1 for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 09:52:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJHEn-0003gf-SQ for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 09:52:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46256 X-GNU-PR-Package: emacs Original-Received: via spool by 46256-submit@debbugs.gnu.org id=B46256.161521509414137 (code B ref 46256); Mon, 08 Mar 2021 14:52:01 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 8 Mar 2021 14:51:34 +0000 Original-Received: from localhost ([127.0.0.1]:42502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJHEM-0003fx-BD for submit@debbugs.gnu.org; Mon, 08 Mar 2021 09:51:34 -0500 Original-Received: from mail-ot1-f50.google.com ([209.85.210.50]:45539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJHEK-0003fk-Cx for 46256@debbugs.gnu.org; Mon, 08 Mar 2021 09:51:33 -0500 Original-Received: by mail-ot1-f50.google.com with SMTP id r24so1287828otp.12 for <46256@debbugs.gnu.org>; Mon, 08 Mar 2021 06:51:32 -0800 (PST) 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=EPUbaZF0JJfK8jypQ5FqPqfcgvyORqaXNZX1tkt3b84=; b=HP2C4hCh8MbuSJzgPkwBxKkEtnWdI7nI6i/IQwwOJuqmzPdent3JgE3HOMfWxkPtIK HWnGp1vCo2jQAqR4dFWPVbkd7qnC82HEgpI71PHsKEIk961qN6ELMLTVlz8jfUNkwl5+ H7FZVoQ6Pz9P1Gx7ZfCE6iCgeh268hqLK6Zqj36a9WXED40t3DGfvkPWUbtyU88Rojbv 75BjtXQUxbEL2jSPsFvfXqL5YjWTFCFRSm3j+X9Xpb/VUOTQ8EZ++3tOSx1/AibHeNXD 9hXKNPMMfv1CPhHNgme9R1qV3/l3ZDHN/TIv/A+F+nrIvxeXsNDZbZM4P1gQTQlmxBf0 LK8g== 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=EPUbaZF0JJfK8jypQ5FqPqfcgvyORqaXNZX1tkt3b84=; b=Jo7C2qO0WgWJCjqGUWQemd4SF+ZkD7OBCyAdG90TivvjuLxb7N44JRHgxk+0diJUnC awSK9mKKWjBuk7ltpzZJnHTD3FVpIlqK3eRIu0Mx1MJsrfmtQ0du7ij7gyz/XRCIQjhD TNlRfzMvikthKpnmPW0hVRj5E37AA38rfIvYWY/ODXkXuI0GpQ0Wzy+ToDFQSpR6MT3s eaRViCnUo06ua35ottoFC9hcI8OsGbGo+F8SelbDG0QuhWmZTkvD5VLYPklkh+McOAEw gxHSX47VYcmZiita3nkT/BRHsK4RmWSRXZHwPUdhW9zMvMyPuIaJT0BG9svyKfdLxP+e SUQw== X-Gm-Message-State: AOAM533SV2bDbjcQX/p3vrsn8URhTKajciQlZIs+eprsXDCiyYKfn6i6 8JnmfJIHxpMW3PbrzOyNexk4DD8VVFTolPN+7JM= X-Google-Smtp-Source: ABdhPJyXbhwCAerY2Od3uOVYq+i3X7SMPyDTjOTNU5WxqwXmd2dY5RINmU/ZzGIVSqgMkPNB1ETMZPxnUetNVewMLOA= X-Received: by 2002:a05:6830:1011:: with SMTP id a17mr17871893otp.154.1615215086609; Mon, 08 Mar 2021 06:51:26 -0800 (PST) In-Reply-To: <83blbtso9k.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:201838 Archived-At: On Mon, Mar 8, 2021 at 2:39 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 8 Mar 2021 13:52:49 +0000 > > Cc: Andrea Corallo , 46256@debbugs.gnu.org, andrewjmoreton@gmail.com > > > > > > Wait, I thought this was on Windows? > > > > > > Yes, and...? > > > > No dlclose() on Windows. > > Why does this matter in this case? (And I do have dlclose in a > standard library that comes with MinGW, btw. Not that it's relevant.) We don't use dlclose() on Windows. FreeLibrary() is documented not to unload the library in certain cases, and to return a failure code. > > FreeLibrary() is documented to behave differently from dlclose() > > It is? In what way? Libraries can be pinned, and it can fail without a clear list of potential failure reasons in the documentation. Not that dlclose() is better according to the documentation, but there, the source is available... > > and I don't have a Windows system to test whether it's actually > > different in practice. > > Well, how about explaining the details in terms that are simple enough > that I could understand and do the testing? Excellent idea. I'll try! > Until now, you and Andrea > have been talking Chinese as far as I'm concerned. Please be aware > that I don't know half the details you two do about native-comp > internals, and will never be able to know that: too many other things > on my plate and too little time. Can you perhaps explain the issue > without alluding to CU_1, CU_2, Fnative_elisp_load etc., and without > assuming that their interactions are common knowledge? Native-comp uses a pseudo-vector type representing a dlopen()ed handle. In addition to the handle being stored in the pseudo-vector, a pointer to the pseudo-vector is stored in the data space belonging to the handle. I'll refer to that as the "reverse pointer" because I can't think of a better term right now. When we cleanup the pseudo-vector, we don't reset the reverse pointer to NULL, or Qnil. That is because we assume that the dlclose() we perform on cleanup will unmap the data space belonging to the handle, anyway. That assumption is wrong in certain specific circumstances. In those circumstances, the reverse pointer is dereferenced after the vector has been deallocated. It points to a random different vector now. > > > Why would any of the above assumptions be violated? > > > > I have several suspicions, including "because the second compilation > > unit referring to the same handle hasn't been collected". Because that > > is definitely a bug, and one we should fix, and then we can debug this > > issue more if and when it reappears. > > More Chinese. (Upon rereading, I agree. My bad.) One of the circumstances in which the assumption (that the reverse pointer won't be used) becomes invalid is when two pseudo-vectors share a handle (and, thus, a reverse pointer). But the reverse pointer can only point to one of them, and it might be the wrong one. My patch, thus, resets the reverse pointer to Qnil when cleanup is performed. In addition, it does so only if the reverse pointer actually pointed to the pseudo-vector being cleaned-up, rather than to a different one, to handle a corner case in the code. Pip