[Bug dynamic-link/29317] New: dlsym with RTLD_DEFAULT causes library to be marked as NODELETE (preventing unloading)

[Bug dynamic-link/29317] New: dlsym with RTLD_DEFAULT causes library to be marked as NODELETE (preventing unloading)

[64.delta at proton dot me]

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

            Bug ID: 29317
           Summary: dlsym with RTLD_DEFAULT causes library to be marked as
                    NODELETE (preventing unloading)
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: 64.delta at proton dot me
  Target Milestone: ---

Here is a reproducer, using glibc version 2.35:

$ cat main.c
#include <dlfcn.h>
#include <assert.h>

int main() {
    void *foo = dlopen("libfoo.so", RTLD_GLOBAL | RTLD_NOW);
    assert(foo);

    void *sym = dlsym(RTLD_DEFAULT, "foo");
    // void *sym = dlsym(foo, "foo");
    assert(sym);

    dlclose(foo);

    assert(!dlopen("libfoo.so", RTLD_NOLOAD | RTLD_NOW));
}
$ cat libfoo.c
void foo() {}
$ gcc libfoo.c -shared -o libfoo.so
$ gcc main.c -D_GNU_SOURCE -Wl,-rpath=. && ./a.out
a.out: main.c:14: main: Assertion `!dlopen("libfoo.so", RTLD_NOLOAD |
RTLD_NOW)' failed.

---

Running with LD_DEBUG=all reveals that 'marking ./libfoo.so [0] as NODELETE due
to reference to main program' is printed during the call to dlsym.

If instead the commented line is used in favour of the line above, then the
assertion passes and no such log is printed.

As far as I'm aware there's nothing about RTLD_DEFAULT which would require the
library be marked as NODELETE, so I assume this is a bug.

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

[Bug dynamic-link/29317] dlsym with RTLD_DEFAULT causes library to be marked as NODELETE (preventing unloading)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |fweimer at redhat dot com
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-07-05

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
I looked at the implementation and it looks like this is done deliberately.
(It's also not a regression.)

I assume it's done to mimic regular symbol binding, which records dependency
information as well.

Could you share more context why this is problematic for your application,
please?

(The log message is misleading, it should say “reference FROM main program”,
I'll post a patch to fix that.)

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

[Bug dynamic-link/29317] dlsym with RTLD_DEFAULT causes library to be marked as NODELETE (preventing unloading)

[64.delta at proton dot me]

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

--- Comment #2 from Matt <64.delta at proton dot me> ---
> Could you share more context why this is problematic for your application, please?

This isn't a particularly problematic issue; rather something I stumbled upon
when testing another dynamic linker. I just think it's fair for users to assume
that dlclose() would unload the library here.

> (The log message is misleading, it should say “reference FROM main program”, I'll post a patch to fix that.)

Much appreciated.

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

[Bug dynamic-link/29317] dlsym with RTLD_DEFAULT causes library to be marked as NODELETE (preventing unloading)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|WAITING                     |RESOLVED

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
Given that the proposed change impacts backwards compatibility and there is no
application impact that prompts this change, I'm closing this is as NOTABUG.

I'll see if I can add something to the manual about the dependency tracking,
and instructions how to avoid it in cases where it is not wanted.

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