This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/17702] New: Support recursive dlopen.
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 12 Dec 2014 01:48:44 +0000
- Subject: [Bug dynamic-link/17702] New: Support recursive dlopen.
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17702
Bug ID: 17702
Summary: Support recursive dlopen.
Product: glibc
Version: 2.20
Status: NEW
Severity: normal
Priority: P2
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: carlos at redhat dot com
The ability to recursively call dlopen is useful for malloc implementations
that wish to load other dynamic modules that implement reentrant/AS-safe
functions to use in their own implementation.
Given that a user malloc implementation may be called by an ongoing dlopen to
allocate memory the user malloc implementation interrupts dlopen and if it
calls dlopen again that's a reentrant call.
At present there are two problems with this:
(a) The first dlopen to return unmaps the ld.so.cache from memory resulting in
any outer dlopens potentially referencing unmapped data (if they were in the
middle of looking up an entry in the cache when they themselves called malloc).
(b) There is code that asserts that _r_debug is RT_CONSISTENT when dlopen is
entered. This may not be true because we may be inside another dlopen.
The solution is to:
(1) Change _dl_load_cache_lookup to return a copy of the mapping data, and make
the copy using alloca/strcpy first to prevent malloc from interrupting the copy
and potentially unmapping the cache.
(2) Remove the assertion that _r_debug should be RT_CONSISTENT.
(3) Work with the gdb team and write up a description of how _r_debug behaves,
and specifically how it behaves during recursive dlopen.
--
You are receiving this mail because:
You are on the CC list for the bug.