This is the mail archive of the
mailing list for the glibc project.
[Bug dynamic-link/25112] dlopen must not make new objects accessible when it still can fail with an error
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 27 Nov 2019 20:21:12 +0000
- Subject: [Bug dynamic-link/25112] dlopen must not make new objects accessible when it still can fail with an error
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Florian Weimer <firstname.lastname@example.org>:
Author: Florian Weimer <email@example.com>
Date: Wed Nov 27 16:37:17 2019 +0100
Avoid late dlopen failure due to scope, TLS slotinfo updates [BZ #25112]
This change splits the scope and TLS slotinfo updates in dlopen into
two parts: one to resize the data structures, and one to actually apply
the update. The call to add_to_global_resize in dl_open_worker is moved
before the demarcation point at which no further memory allocations are
_dl_add_to_slotinfo is adjusted to make the list update optional. There
is some optimization possibility here because we could grow the slotinfo
list of arrays in a single call, one the largest TLS modid is known.
This commit does not fix the fatal meory allocation failure in
_dl_update_slotinfo. Ideally, this error during dlopen should be
The update order of scopes and TLS data structures is retained, although
it appears to be more correct to fully initialize TLS first, and then
expose symbols in the newly loaded objects via the scope update.
Tested on x86_64-linux-gnu.
You are receiving this mail because:
You are on the CC list for the bug.