From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Mon, 08 Mar 2021 19:40:27 +0200 Message-ID: <83sg55r1bo.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5535"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com, akrl@sdf.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 08 19:44:13 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 1lJKrU-0001KQ-F9 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 19:44:12 +0100 Original-Received: from localhost ([::1]:55722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJKrT-0001CE-HB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 13:44:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJJsP-00082H-Vx for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 12:41:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJJsM-0001ow-Il for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 12:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJJsM-0002CU-Gy for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 12:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 17:41:02 +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.16152252478429 (code B ref 46256); Mon, 08 Mar 2021 17:41:02 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 8 Mar 2021 17:40:47 +0000 Original-Received: from localhost ([127.0.0.1]:44706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJJs7-0002Bt-AA for submit@debbugs.gnu.org; Mon, 08 Mar 2021 12:40:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJJs2-0002Bd-Jn for 46256@debbugs.gnu.org; Mon, 08 Mar 2021 12:40:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52516) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJJrw-0001gw-7O; Mon, 08 Mar 2021 12:40:36 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3683 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lJJrv-0000jD-KE; Mon, 08 Mar 2021 12:40:35 -0500 In-Reply-To: (message from Pip Cet on Mon, 8 Mar 2021 14:50:50 +0000) 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:201865 Archived-At: > From: Pip Cet > Date: Mon, 8 Mar 2021 14:50:50 +0000 > Cc: Andrea Corallo , 46256@debbugs.gnu.org, andrewjmoreton@gmail.com > > > 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! Thanks. Somewhat clearer now, but I'm still not out of the woods yet. Bear with me. > Native-comp uses a pseudo-vector type representing a dlopen()ed handle. You mean, the Lisp_Native_Comp_Unit structure? If so, it doesn't really represent a handle, AFAIU, it represents a .eln file we loaded. Right? > 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. Why do we need this reverse pointer, and how do we use it? > When we cleanup the pseudo-vector, we don't reset the reverse pointer > to NULL, or Qnil. What do you mean by "cleanup" here? Under what circumstances does it happen? And no, Qnil won't do, because a Lisp_Object can be wider than a pointer (it is in the 32-bit build --with-wide-int). NULL is fine. > That is because we assume that the dlclose() we perform on cleanup > will unmap the data space belonging to the handle, anyway. But the call to dlclose doesn't happen immediately, it only happens in GC. Right? (A nit: please don't use "foo()" to refer to a function, because that looks like a call to 'foo' with no arguments, which is not what you mean.) > 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. I need to understand the circumstances under which this could happen. If the vector has been deallocated, it means it was GC'ed, right? And if it was GC'ed, how come the .eln was not unloaded? > 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). How can that happen? can you describe a series of events that make this possible? > My patch, thus, resets the reverse pointer to Qnil when cleanup is > performed. You can't use Qnil, for the reasons described above. P.S. The stuff described in this sub-thread should eventually find its way into comments in comp.c.