From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0B3123858D1E; Wed, 9 Feb 2022 21:27:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B3123858D1E From: "aral at gmx dot de" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/28877] New: second call to dlopen fails to load a modified library binary Date: Wed, 09 Feb 2022 21:27:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: aral at gmx dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 21:27:17 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28877 Bug ID: 28877 Summary: second call to dlopen fails to load a modified library binary Product: glibc Version: 2.28 Status: NEW Severity: enhancement Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: aral at gmx dot de Target Milestone: --- Scenario to reproduce requires: - main application able to load/unload plugin.so on e.g. user keypress - plugin.so with function void printVersion() { printf( "1\n" ); } 1) main is started & loads "plugin.so"=20 2) main executes plugin's printPluginVersion -> "1" 3) main waits for user key press 4) plugin.so is modified to print "2" as version and recompiled 5) main is triggered to reload plugin (e.g. via keypress) 6) main unloads plugin.so via dlclose 7) main reloads plugin.so via dlopen 8) main executes plugin's printPluginVersion -> "1"(!!) The new version of the plugin binary has not been loaded. An application restart will load the new version as expected in step 1 & 2 I believe the standard description for dlclose at https://pubs.opengroup.org/onlinepubs/007904975/functions/dlclose.html is related, stating: "Although a dlclose() operation is not required to remove structures from an address space, neither is an implementation prohibited from doing so." It appears as though dlclose in the glibc does not remove the plugin from t= he address space and the subsequent dlopen just re-uses the already loaded plu= gin. As it seems to be not prohibited by the standard, I would like to propose t= hat dlopen *always* loads the requested library from the file system, and there= by the newest version. Workaround that works as intended: string tempLink =3D randomFilenameOnSamePartition(); link( file, tempLink.c_str() ); // create a hard link to file // attempt to open file via the hard link void *libraryHandle =3D dlopen( tempLink.c_str(), mode ); unlink( tempLink.c_str() ); // delete the hard link right after use If needed, I will be able to provide a proof of concept on the weekend. But= it seems to be a 100% reproducible behavior and I could not find a different report on this. The closest related bug report seems to be https://sourceware.org/bugzilla/show_bug.cgi?id=3D16805 --=20 You are receiving this mail because: You are on the CC list for the bug.=