From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13071 invoked by alias); 27 Oct 2006 17:31:48 -0000 Received: (qmail 12981 invoked by uid 48); 27 Oct 2006 17:31:30 -0000 Date: Fri, 27 Oct 2006 17:31:00 -0000 From: "suzuki at in dot ibm dot com" To: glibc-bugs@sources.redhat.com Message-ID: <20061027173127.3429.suzuki@in.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/3429] New: Race in _dl_open with r_debug.r_state consistency check X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00133.txt.bz2 List-Id: 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.