# /lib/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1252: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! It can be cleaned up by the following: http://216.239.51.104/search?q=cache:ui1T421ec7gJ:sources.redhat.com/ml/libc-alpha/2003-10/msg00011.html+Assertion+%60_rtld_local._dl_rtld_map.l_prev-%3El_next&hl=en&ie=UTF-8 --- rtld.c 24 Sep 2003 01:55:51 -0000 1.293 +++ rtld.c 30 Sep 2003 14:25:50 -0000 @@ -1223,19 +1223,7 @@ of this helper program; chances are you while (GL(dl_loaded)->l_searchlist.r_list[i] != &GL(dl_rtld_map)) ++i; GL(dl_rtld_map).l_prev = GL(dl_loaded)->l_searchlist.r_list[i - 1]; - if (__builtin_expect (mode, normal) == normal) - GL(dl_rtld_map).l_next = (i + 1 < GL(dl_loaded)->l_searchlist.r_nlist - ? GL(dl_loaded)->l_searchlist.r_list[i + 1] - : NULL); - else - /* In trace mode there might be an invisible object (which we - could not find) after the previous one in the search list. - In this case it doesn't matter much where we put the - interpreter object, so we just initialize the list pointer so - that the assertion below holds. */ - GL(dl_rtld_map).l_next = GL(dl_rtld_map).l_prev->l_next; - - assert (GL(dl_rtld_map).l_prev->l_next == GL(dl_rtld_map).l_next); + GL(dl_rtld_map).l_next = GL(dl_rtld_map).l_prev->l_next; GL(dl_rtld_map).l_prev->l_next = &GL(dl_rtld_map); if (GL(dl_rtld_map).l_next != NULL) {
I was wondering when a patch for this would be found. I know Azarah sent a mail to libc-alpha about it, but as far as I know, no one ever responded to his question. I'll have to give this a run and see what it does.
Actually, solar found this, and I applied it successfully to the (athlon) machines I have 2.6 kernels on. It sure seems to have done the trick here.
This silly rtld is still borked in the latest glibc snapshot. Same patch as for 2.3.2 still makes this executable without complaint. goonie glibc # /lib/libc.so.6 Inconsistency detected by ld.so: rtld.c: 1295: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! goonie glibc # emerge -p glibc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-libs/glibc-2.3.3_pre20040117 EXPECTED RESULT: goonie files # /lib/libc.so.6 GNU C Library stable release version 2.3.3, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7). Compiled on a Linux 2.6.1-gentoo system on 2004-02-02. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others NPTL 0.60 by Ulrich Drepper BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Report bugs using the `glibcbug' script to <bugs@gnu.org>.
I tried this patch awhile back, and I still got the error. Maybe I did something wrong. I'll have to try again later on, my x86 box got toasted by what appears to now be bad ram.
This is what I get with this patch: -- # /lib/libc-2.3.3.so Inconsistency detected by ld.so: rtld.c: 1295: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! -- and for the record, I _did_ mail to list, but no reply ...
ok, please tell me you at least get that rtld complaint *without* the patch. Did it get added in a conditional part of the ebuild or undone by some other patch? In my build, I apply it right after the branch update: if [ -n "${BRANCH_UPDATE}" ] then epatch ${DISTDIR}/${PN}-${PV/_*}-branch-update-${BRANCH_UPDATE}.patch.bz2 fi cd ${S}; epatch ${FILESDIR}/2.3.2/glibc-2.3.2-rtld.patch # emerge -pv glibc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-libs/glibc-2.3.3_pre20040117-r1 -build +nls +nptl +pic 0 kB Total size of downloads: 0 kB
Sorry, that was me being braindead. I hand edited the file in an existing built tree, and then re-made it. I just copied libc.so and not ld.so over to / =) Anyhow, seems like it fixes this issue. I will add to next -r for testing.
Added to glibc-2.3.3_pre20040207.
can we have this bug fix as well? $ /lib/ld-linux.so.2 /lib/ld-linux.so.2 Inconsistency detected by ld.so: rtld.c: 979: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
That is legal? If so, add a new bug please.
I've just recompiled glibc (to add nptl support) and I'm still getting this error message. I looked in the ebuild directory and noticed that this patch is only being applied to glibc-2.3.3_pre20040207.ebuild Is it safe to add this to glibc-2.3.2-r9.ebuild?
I support #11, could this patch please be added to the latest stable glibc (sys-libs/glibc-2.3.2-r9)? I don't think there'll be a new stable 2.3.3 anytime soon. It's somewhat annoying to not get any version-info.
This has still not been fixed, using the latest 2.3.4 snapshot. What's going on?
Add emerge info please ----- azarah@nosferatu ~ $ /lib/ld-2.3.4.so Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we can handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names in LIST azarah@nosferatu ~ $ /lib/libc-2.3.4.so GNU C Library stable release version 2.3.4, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.5 20050130 (Gentoo Linux 3.3.5.20050130, ssp-3.3.5.20050130-1, pie-8.7.7.1). Compiled on a Linux 2.6.8 system on 2005-02-12. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. azarah@nosferatu ~ $
