From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: kris Newsgroups: gmane.emacs.bugs Subject: bug#38368: gcc/ dlclose() documentation feedback Date: Mon, 25 Nov 2019 02:58:42 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="154267"; mail-complaints-to="usenet@blaine.gmane.org" To: 38368@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 25 22:36:38 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iZM29-000dzF-Pa for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Nov 2019 22:36:37 +0100 Original-Received: from localhost ([::1]:48414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZM28-0000sJ-Kh for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Nov 2019 16:36:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59729) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZLzJ-0006VR-6W for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2019 16:33:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZLzH-0003Xq-V9 for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2019 16:33:41 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43800) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZLzH-0003Xe-Mk for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2019 16:33:39 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iZLzH-0002W4-K5 for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2019 16:33:39 -0500 X-Loop: help-debbugs@gnu.org Resent-From: kris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Nov 2019 21:33:39 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 38368 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.157468668921327 (code B ref -1); Mon, 25 Nov 2019 21:33:39 +0000 Original-Received: (at submit) by debbugs.gnu.org; 25 Nov 2019 12:58:09 +0000 Original-Received: from localhost ([127.0.0.1]:47858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZDwP-0005Xt-0w for submit@debbugs.gnu.org; Mon, 25 Nov 2019 07:58:09 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:49370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZDqU-0005JQ-4w for submit@debbugs.gnu.org; Mon, 25 Nov 2019 07:52:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43131) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZ3eH-0006mB-8s for bug-gnu-emacs@gnu.org; Sun, 24 Nov 2019 20:58:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZ3eG-0005ab-8F for bug-gnu-emacs@gnu.org; Sun, 24 Nov 2019 20:58:45 -0500 Original-Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]:39895) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZ3eG-0005aU-4w for bug-gnu-emacs@gnu.org; Sun, 24 Nov 2019 20:58:44 -0500 Original-Received: by mail-qk1-x734.google.com with SMTP id z65so6575350qka.6 for ; Sun, 24 Nov 2019 17:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sSZ63YYvHlNx/YNFAttr7I2OdmqG+JV9s9n7O2sTk3Q=; b=uGcHV/mUlfSjjih7zvfNX6rgsJdClLZpJeUsQhqbq9kt7JvLPmMCFif17oEiUHr59N CsKADOa2rlNhZ1XbT7vz2JAoFiBRHeFIoFmIgHFMHghWrXaXNhHeSWNG4bgVSJ4wnwZ3 OEdZ2WYbYwKp/AfiqIi/TdBfNc/gLuLoXeYxByBBk5wfM9SEiTIMe+MxMtq0djJKi1Qh RzWvBr6TdN1kqC09OZTxPgva99t8FV9MnCaunLy6lBwHyUQZjCPgIV93UbH4DTgCbggq Uuav9ixPOSTs/U/XjGYE2o29QkDawkZf4HRTTQeqRDwnOBPfBPPZtz9rlJVy50vWwOU/ ZAOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sSZ63YYvHlNx/YNFAttr7I2OdmqG+JV9s9n7O2sTk3Q=; b=Uo0co6tV4DGeylzdXc05fePWfDahFKFa3wcZcgfkEwTH+dlnAlfS36ahYEVfsLikTF O5Kh8kwAgCGbPPWWj8B/74FJZT33+Ndsc4E739xkhYNoU9v40wGCEBnFmERbELt6vuFt OmAHU5obRpBV1pPqEefwL3NVTIVv0vmmR5wr3xP906MAWjfqLeCREP62v2Ta4WpqbcP3 WAlD8EMo+znKcsEZJXsaK2UrDCNKZ8IcfxUqeB6ybhxZkM5lyUhQoHJKmU3fyCL1giR2 W7jLCzqKENaGb1RSYpcjQtoknF1VOWhSFLyaKw7Brkvua+888bxC37ajIvqYZHHrd/t4 e7sg== X-Gm-Message-State: APjAAAVGDzSaA8rUtlW2DLRa+q+iouPdCDnEmL/oHDLtNCpuBd7TMXZp CbxhZjw1mwIUZeDxc7SFObgrRtHBgZmuQdKvPcfICw== X-Google-Smtp-Source: APXvYqyColgM5aaRwk3iIVCxLa4Q1/jWUHehnogqs/GmI/KzlzAhsbttSULF+d0fVOuhhjIdJLlP4AR5hztqDQ0LUpM= X-Received: by 2002:a05:620a:3dd:: with SMTP id r29mr24714882qkm.370.1574647123320; Sun, 24 Nov 2019 17:58:43 -0800 (PST) Original-Received: by 2002:a0c:e306:0:0:0:0:0 with HTTP; Sun, 24 Nov 2019 17:58:42 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172381 Archived-At: hello I think there is some ambiguity in the man page for dlclose(). *********** A successful return from dlclose() does not guarantee that the symbols associated with handle are removed from the caller's address space. In addition to references resulting from explicit dlopen() calls, a shared object may have been implicitly loaded (and reference counted) because of dependencies in other shared objects. Only when all references have been released can the shared object be removed from the address space. ******** that strikes me as undermining the docs for RTLD_NOLOAD in the same page which say that residency CAN be tested. i do the following to ensure the object is unloaded: void *handle = dlopen(path,RTLD_NOW | RTLD_NOLOAD); if(handle){ return(dlclose(handle) || dlclose(handle) ); } ... it appears to take 2 calls to achieve the unload which I presume means the refcount got incremented by this dlopen() despite the RTLD_NOLOAD. then I test again this way and the 2nd dlclose() fails and confirms the object is unloaded. or so I thought. this worked until I came to recursively load a chain of objects (not automatically) and then tried reloading the 1st in the chain. despite doing the above closing sequence on the chain in reverse order and finally on the head of the chain, before doing another dlopen() with a new version of the disk file, I found that extracting the data from the address returned from a dlsym() yielded old data. I have to conclude that the object unload does NOT happen and that the above dlopen(RTLD_NOLOAD)/dlclose() test is erroneous (at least in this layered arrangement). so getting back to the original ambiguity claim, the passage mentions removing symbols in the first instance then switches to 'references being released' the next. what are 'references' (symbols?) and how does one determine anything about them or rather enough to 'release' them so as to circumvent the lack of a guarantee from dlclose() ? I have scoured the available docs and can find no more on how to ascertain what prevents unloading or how such can be addressed. I hope you agree there is at least a lack of clarity. thanks for reading.