[Bug dynamic-link/28877] New: second call to dlopen fails to load a modified library binary

[Bug dynamic-link/28877] New: second call to dlopen fails to load a modified library binary

[aral at gmx dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=28877

            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" 
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 the
address space and the subsequent dlopen just re-uses the already loaded plugin.

As it seems to be not prohibited by the standard, I would like to propose that
dlopen *always* loads the requested library from the file system, and thereby
the newest version.

Workaround that works as intended:
  string tempLink = randomFilenameOnSamePartition();
  link( file, tempLink.c_str() ); // create a hard link to file

  // attempt to open file via the hard link
  void *libraryHandle = 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=16805

-- 
You are receiving this mail because:
You are on the CC list for the bug.