Launchpad has imported 19 comments from the remote bug at http://sourceware.org/bugzilla/show_bug.cgi?id=12454.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-01-30T17:25:07+00:00 octoploid wrote: I've hit the following assert running glibc 2.13 on Linux x86_64: Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! This is caused by the following commit: http://sourceware.org/git/?p=glibc.git;a=commit;h=968dad0ab1f367a087ff4ad503b511dd0c565adc Reverting the commit "solves" the problem. There are two ways to reproduce the problem on my machine. 1) Trying to start sage ( http://www.sagemath.org/ ) 2) Changing outputs in mpd ( http://mpd.wikia.com ) Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/0 ------------------------------------------------------------------------ On 2011-01-30T21:58:32+00:00 octoploid wrote: Created attachment 5220 replace assert by if Here's an ugly patch that fixes the issue for me. Instead of "assert (nlist > 1);" wrap the whole while loop with "if (nlist > 1)". Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/1 ------------------------------------------------------------------------ On 2011-02-05T19:43:28+00:00 octoploid wrote: Created attachment 5229 Don't call _dl_sort_fini if there is only one object. (part 2) Only call _dl_sort_fini in dl-close.c if there is more than one object. This patch fixes: gcc -nostdlib -nostartfiles -static -o /var/tmp/glibc-build/elf/tst-tls9-static -Wl,-O1,--hash-style=gnu,--as-needed /var/tmp/glibc-build/csu/crt1. o /var/tmp/glibc-build/csu/crti.o `gcc --print-file-name=crtbegin.o` /var/tmp/glibc-build/elf/tst-tls9-static.o /var/tmp/glibc-build/dlfcn/libdl.a /var/tmp/glibc-build/libc.a -lgcc -lgcc_eh /var/tmp/glibc-build/libc.a `gcc --print-file-name=crtend.o` /var/tmp/glibc-build/csu/crtn.o /var/tmp/glibc-build/elf/tst-tls9-static.o: In function `do_test': /var/tmp/glibc/elf/tst-tls9.c:16: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc v ersion used for linking GCONV_PATH=/var/tmp/glibc-build/iconvdata LC_ALL=C LD_LIBRARY_PATH=/var/tmp/glibc-build/elf/:/var/tmp/glibc-build/:/var/tmp/glibc-build/dlfcn /var/t mp/glibc-build/elf/tst-tls9-static > /var/tmp/glibc-build/elf/tst-tls9-static.out tst-tls9-static: dl-fini.c:38: _dl_sort_fini: Assertion `nmaps > 1' failed. Didn't expect signal from child: got `Aborted' make[2]: *** [/var/tmp/glibc-build/elf/tst-tls9-static.out] Error 1 make[2]: Leaving directory `/var/tmp/glibc/elf' Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/2 ------------------------------------------------------------------------ On 2011-02-18T20:31:51+00:00 Carlos-systemhalted wrote: I've also seen this on x86 with glibc 2.13 git trunk, where it effects the testsuite causing tst-cancel24, tst-chk4, tst-chk5, tst-chk6, tst- lfschk4, tst-lfschk5, and tst-lfschk6 to fail with "Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!". Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/5 ------------------------------------------------------------------------ On 2011-02-18T23:49:21+00:00 Kees Cook wrote: Created attachment 5253 combined fixes Here's a combined version of the fixes that doesn't mess with indenting and has the same effect. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/12 ------------------------------------------------------------------------ On 2011-02-19T03:28:10+00:00 Carlos-systemhalted wrote: The patches attached to this issue still do not address why they are required, and what's actually wrong with the code, or why the original commit is not correct. Until those questions are addressed it is unlikely that this patch will make it into glibc. Can anyone answer "Why?" Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/18 ------------------------------------------------------------------------ On 2011-02-21T09:19:08+00:00 Andreas Schwab wrote: http://sourceware.org/ml/libc-hacker/2011-02/msg00002.html Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/23 ------------------------------------------------------------------------ On 2011-02-21T16:12:34+00:00 Carlos-systemhalted wrote: (In reply to comment #6) > http://sourceware.org/ml/libc-hacker/2011-02/msg00002.html Andreas, Thanks, this helped pinpoint the defect in the sysroot I was using. Rather than getting an assert I get something useful now. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/26 ------------------------------------------------------------------------ On 2011-02-21T17:32:33+00:00 Others-fredlwm wrote: I patched glibc 2.13 git and recompiled it. I then compiled elfutils 0.152 and recompiled prelink 20101123. Running the prelink testsuite, one test failed: ../src/prelink -c ./prelink.conf -C ./prelink.cache --ld-library-path=. --dynamic-linker=./ld-linux.so.2 -vm ./reloc11 ../src/prelink: ./reloc11lib1.so: Could not parse `Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed! After that, running prelink, the usual "Could not find one of the dependencies" for missing dependencies. I have no idea why the test failed. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/27 ------------------------------------------------------------------------ On 2011-02-21T23:23:26+00:00 Carlos-systemhalted wrote: If the prelink testsuite is failing then I recommend contacting the prelink developers and asking for their help in putting together a test case that reproduces the problem. Until this issue has a reduced test case it's going to be difficult to determine what's wrong. A reduced test case contains the *exact* steps to reproduce the problem, along with source, and pre-processed source. It is not acceptable to post-process a binary and say that the post- processed binary fails. It could be a problem with the post-processing tool. Could you please provide a reduced test case? Thanks! Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/28 ------------------------------------------------------------------------ On 2011-02-22T00:04:05+00:00 Others-fredlwm wrote: I don't know how to reproduce it without running prelink. Here, it can be reproduced with the following, extracted from the testsuite. A file named reloc10lib4.c with just int dummy = 24; $ gcc -shared -O2 -nostdlib -fpic -o reloc11lib1.so reloc10lib4.c $ prelink reloc11lib1.so prelink: reloc11lib1.so: Could not parse `Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed!' Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/29 ------------------------------------------------------------------------ On 2011-02-22T01:30:28+00:00 MikeFrysinger wrote: if you `ldd` that file, do you get the same error ? Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/30 ------------------------------------------------------------------------ On 2011-02-22T01:53:27+00:00 Others-fredlwm wrote: (In reply to comment #11) > if you `ldd` that file, do you get the same error ? Yes, so no need to have prelink. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/31 ------------------------------------------------------------------------ On 2011-02-22T15:04:27+00:00 Carlos-systemhalted wrote: Ulrich, Could you please verify? This reproduces for me on trunk and 2.13 on x86. Steps to reproduce: cat > test.c <<EOF int dummy=64; EOF gcc -shared -fpic -o libtest.so test.c Observed output: ~~~ LD_TRACE_LOADED_OBJECTS=1 /home/carlos/build/glibc/elf/ld.so ./libtest.so Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed! ~~~ Expected output (created using system ld.so based on 2.12): ~~~ LD_TRACE_LOADED_OBJECTS=1 /lib/ld-2.12.1.so ./libtest.so linux-gate.so.1 => (0x00961000) libc.so.6 => /lib/libc.so.6 (0x0026f000) /lib/ld-2.12.1.so (0x00cdf000) ~~~ I have not done any analysis other than reproducing the problem. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/32 ------------------------------------------------------------------------ On 2011-02-25T21:52:13+00:00 Drepper-fsp wrote: I used Andreas's patch which in any case is OK. If this isn't the entire fix, reopen. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/34 ------------------------------------------------------------------------ On 2011-02-26T07:40:18+00:00 octoploid wrote: Ulrich, did you ever run Carlos testcase before closing this bug? Apparently not, because the bug is still present even with Andreas' patch applied. Without Kees' patch (testcase from comment 10): /libx32/ld-linux-x32.so.2 --list ./reloc11lib1.so Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed! With Kees' patch: /libx32/ld-linux-x32.so.2 --list ./reloc11lib1.so statically linked It's your code that is calling these (bogus) assertions. Could you at least think about it for a few minutes before closing this bug again without a real fix in six weeks (which seems to be your average latency lately)?. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/35 ------------------------------------------------------------------------ On 2011-03-13T16:04:53+00:00 Jeff Chua wrote: > It's your code that is calling these (bogus) assertions. > Could you at least think about it for a few minutes before closing this > bug again without a real fix in six weeks (which seems to be your average > latency lately)?. Latest git pull (commit c6e13027abd4b9c2d694fb4d8b28ab8290ea5971) still not fixed. Applying both Octoploid's part 1 and 2 fixed Vmware 7.1.3 below: Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed! Thanks, Jeff Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/36 ------------------------------------------------------------------------ On 2011-04-25T19:59:58+00:00 JVD wrote: still happening with 2.13 ( GIT checkout of @2011-04-04, 'git checkout -f glibc-2.13' ) , for any shared object for 32-bit sub-arch on x86_64, that is linked with '-nostdlib' : 1. 32-bit fails: $ echo 'int r = 42;' > rc.c $ gcc -m32 -shared -fPIC -o rc.so rc.c $ /lib32/ld-2.13.so --list ./rc.so linux-gate.so.1 => (0xf7757000) libc.so.6 => /lib32/libc.so.6 (0xf75d6000) /lib32/ld-2.13.so (0xf7758000) $ gcc -m32 -shared -fPIC -nostdlib -o rc.so rc.c $ /lib32/ld-2.13.so --list ./rc.so Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! 2. 64-bit (native arch) works: $ gcc -shared -o rc.so -fPIC -nostdlib rc.c $ ldd ./rc.so statically linked $ gcc -shared -fPIC -o rc.so rc.c $ /lib/ld-2.13.so --list ./rc.so linux-vdso.so.1 => (0x00007fff3a3ff000) libc.so.6 => /lib64/libc.so.6 (0x00007fad662f9000) /lib/ld-2.13.so (0x00007fad668b5000) Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/37 ------------------------------------------------------------------------ On 2011-04-26T13:20:13+00:00 JVD wrote: Not sure if this is pertinent here, but I suspect so - what I'm seeing is : o no problem if ld.so has no 'DT_RPATH' / 'DT_RPATH_LINK' o problem if using ld.so with non-empty DT_RPATH / DT_RPATH_LINK $ objdump -x /lib64/ld-2.13.so | grep RPATH ^- this bug does NOT happen when using this loader: $ echo 'int i = 42; ' > rc.c $ gcc -o rc.so -shared -nostlib -fPIC rc.c $ /lib64/ld-2.13.so --list ./rc.so statically linked $ objdump -x /lib32/ld-2.13.so | grep RPATH RPATH /mnt/sda3/gcc/./gcc/32/:/mnt/sda3/gcc/./gcc/:/mnt/sda3/gcc/x86_64-pc-linux-gnu/libgcc/32:/mnt/sda3/gcc/x86_64-pc-linux-gnu/libgcc:/usr/lib32:/lib32 ^- bug only happens using this loader : $ gcc -m32 -o rc.so -shared -nostdlib -fPIC rc.c $ /lib32/ld-2.13.so --list ./rc.so Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! Now, in order to build any ld.so at all with an RPATH, you must be somehow disabling this bit of code : $ diff -U0 elf/dynamic-link.h~ elf/dynamic-link.h --- elf/dynamic-link.h~ 2011-04-08 02:03:09.000000000 +0100 +++ elf/dynamic-link.h 2011-04-07 02:59:09.000000000 +0100 @@ -208,2 +208,3 @@ - assert (info[DT_RUNPATH] == NULL); - assert (info[DT_RPATH] == NULL); + /* assert (info[DT_RUNPATH] == NULL); + assert (info[DT_RPATH] == NULL); + */ Now, I remember being roundly upbraded by Uli for attempting something so crazy, with something along the lines of "an RPATH setting for ld.so causes so many problems for the loader it never will be supported" - but I've been building the 32-bit sub-architecture glibc (ONLY!) for x86_64 for years with these lines commented out, hoping to find (and maybe fix?) any problems caused, and running 32-bit freeware such as mozilla plugins against this 32-bit loader, with no problems (except this one!) found so far. Yes, I can see how commenting out these lines would be crazy for a NATIVE loader, but not for a sub-architecture loader such as 32-bit on native 64-bit or vice versa. Reply at: https://bugs.launchpad.net/eglibc/+bug/721469/comments/38 ** Changed in: eglibc Status: Unknown => Confirmed ** Changed in: eglibc Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/721469 Title: program startup fails with "Inconsistency detected by ld.so: dl- deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!" -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
