This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/24304] Lazy binding failure during ELF constructors/destructors is not fatal


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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Florian Weimer <fw@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=79e0cd7b3c997e211fad44a81fd839dc5b2546e8

commit 79e0cd7b3c997e211fad44a81fd839dc5b2546e8
Author: Florian Weimer <fweimer@redhat.com>
Date:   Wed Nov 27 16:20:47 2019 +0100

    Lazy binding failures during dlopen/dlclose must be fatal [BZ #24304]

    If a lazy binding failure happens during the execution of an ELF
    constructor or destructor, the dynamic loader catches the error
    and reports it using the dlerror mechanism.  This is undesirable
    because there could be other constructors and destructors that
    need processing (which are skipped), and the process is in an
    inconsistent state at this point.  Therefore, we have to issue
    a fatal dynamic loader error error and terminate the process.

    Note that the _dl_catch_exception in _dl_open is just an inner catch,
    to roll back some state locally.  If called from dlopen, there is
    still an outer catch, which is why calling _dl_init via call_dl_init
    and a no-exception is required and cannot be avoiding by moving the
    _dl_init call directly into _dl_open.

    _dl_fini does not need changes because it does not install an error
    handler, so errors are already fatal there.

    Change-Id: I6b1addfe2e30f50a1781595f046f44173db9491a

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]