This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/3429] New: Race in _dl_open with r_debug.r_state consistency check
- From: "suzuki at in dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 27 Oct 2006 17:31:30 -0000
- Subject: [Bug libc/3429] New: Race in _dl_open with r_debug.r_state consistency check
- Reply-to: sourceware-bugzilla at sourceware dot org
While running some stress tests on one of our application, we encountered an
assert() in ld.so as follows:
"Inconsistency detected by ld.so: dl-open.c: 610: _dl_open: Assertion
`_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!
with glibc-2.4.31. This race seems to be present in the libc I got from the CVS
[at code inspection]. We were able to reproduce this consistently within 4-5hrs
of run.
Upon debugging we found that it is due to a race between two threads doing a
_dl_open().
The scenario is something like this :
In elf/dl-open.c, _dl_open:
/* Make sure we are alone. */
__rtld_lock_lock_recursive (GL(dl_load_lock));
[...]
int errcode = _dl_catch_error (&objname, &errstring, &malloced,
dl_open_worker, &args);
#ifndef MAP_COPY
/* We must munmap() the cache file. */
_dl_unload_cache ();
#endif
/* Release the lock. */
__rtld_lock_unlock_recursive (GL(dl_load_lock));
^^^^^ This would kick any other thread waiting on the lock.
if (__builtin_expect (errstring != NULL, 0))
{
[...]
assert (_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT);
}
assert (_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT);
And, if the thread which gets woken up is playing with the same namespace, and
sets the r_state to RT_ADD in _dl_map_object_from_fd even before we reach here
(truly possible in an SMP system), ( due to getting scheduled out ), we would
hit the assert !
So, it is not safe to believe that the r_state won't get changed once we release
the lock.
--
Summary: Race in _dl_open with r_debug.r_state consistency check
Product: glibc
Version: 2.4
Status: NEW
Severity: normal
Priority: P1
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: suzuki at in dot ibm dot com
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=3429
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.