[Bug dynamic-link/31164] dlmopen()'ing a shared library that dlopen()'s a non-existent library during initialization returns prematurely

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
I believe this was fixed in glibc 2.34 via this commit:

commit b2964eb1d9a6b8ab1250e8a881cf406182da5875
Author: Florian Weimer <fweimer@redhat.com>
Date:   Wed Apr 21 19:49:51 2021 +0200

    dlfcn: Failures after dlmopen should not terminate process [BZ #24772]

    Commit 9e78f6f6e7134a5f299cc8de77370218f8019237 ("Implement
    _dl_catch_error, _dl_signal_error in libc.so [BZ #16628]") has the
    side effect that distinct namespaces, as created by dlmopen, now have
    separate implementations of the rtld exception mechanism.  This means
    that the call to _dl_catch_error from libdl in a secondary namespace
    does not actually install an exception handler because the
    thread-local variable catch_hook in the libc.so copy in the secondary
    namespace is distinct from that of the base namepace.  As a result, a
    dlsym/dlopen/... failure in a secondary namespace terminates the process
    with a dynamic linker error because it looks to the exception handler
    mechanism as if no handler has been installed.

    This commit restores GLRO (dl_catch_error) and uses it to set the
    handler in the base namespace.

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

(There have been other fixes for ld.so exception handling and dlmopen, and more
generally dlmopen.)

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