From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fw@deneb.enyo.de>
Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21])
 by sourceware.org (Postfix) with ESMTPS id B0CE9395CCB8
 for <libc-help@sourceware.org>; Fri, 20 Nov 2020 11:33:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B0CE9395CCB8
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=deneb.enyo.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de
Received: from [172.17.203.2] (helo=deneb.enyo.de)
 by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 id 1kg4fB-0007DT-3h; Fri, 20 Nov 2020 11:33:13 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.92)
 (envelope-from <fw@deneb.enyo.de>)
 id 1kg4fB-0002AU-0l; Fri, 20 Nov 2020 12:33:13 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: "Wendeborn\, Jonathan via Libc-help" <libc-help@sourceware.org>
Subject: Re: dlopen: Segfault due to overwriting .so file after it was loaded
 and loading it again
References: <11e3703d900d48149d0f81ae7682480f@bruexc101.brumgt.local>
Date: Fri, 20 Nov 2020 12:33:13 +0100
In-Reply-To: <11e3703d900d48149d0f81ae7682480f@bruexc101.brumgt.local>
 (Jonathan via Libc-help Wendeborn's message of "Fri, 20 Nov 2020
 06:52:35 +0000")
Message-ID: <87lfewl0ue.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: libc-help@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-help mailing list <libc-help.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-help/>
List-Help: <mailto:libc-help-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2020 11:33:16 -0000

* Jonathan via Libc-help Wendeborn:

> The destructor ~shared_library() calls dlclose(), but I suspect the
> library stays loaded. Overwriting the file creates a new file node
> and my program wants to load the same library again (at the same
> location but with a different file node/handle).

This crash happens if the file is truncated on disk and rewritten.
All mapped data is reset to zero if that happens and relocations are
gone.  The kernel does that, there is nothing that glibc can do about
it (Linux does not support MAP_COPY).

So you have two issues here: The library stays loaded (maybe it is
marked as NODELETE, LD_DEBUG=3Dall output logs that in recent glibc
versions), and the file is rewritten in place (and not a =E2=80=9Cnew file
node=E2=80=9D is created).