12454 2011-01-30 17:25:00 +0000 Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! 2011-08-04 13:09:05 +0000 1 1 1 Unclassified glibc libc 2.13 All All RESOLVED FIXED https://launchpad.net/bugs/721469 P2 normal --- 1 cryptooctoploid drepper.fsp allan carlos jason.vas.dias jeff.chua.linux marconifabio others toolchain vapier 2011-02-22 15:04:27 46889 cryptooctoploid 2011-01-30 17:25:07 +0000 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 ) 46891 5220 cryptooctoploid 2011-01-30 21:58:32 +0000 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)". 46953 5229 cryptooctoploid 2011-02-05 19:43:28 +0000 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' 47121 carlos 2011-02-18 20:31:51 +0000 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!". 47124 5253 kees 2011-02-18 23:49:21 +0000 Created attachment 5253 combined fixes Here's a combined version of the fixes that doesn't mess with indenting and has the same effect. 47125 carlos 2011-02-19 03:28:10 +0000 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?" 47133 schwab 2011-02-21 09:19:08 +0000 http://sourceware.org/ml/libc-hacker/2011-02/msg00002.html 47134 carlos 2011-02-21 16:12:34 +0000 (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. 47135 others 2011-02-21 17:32:33 +0000 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. 47139 carlos 2011-02-21 23:23:26 +0000 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! 47140 others 2011-02-22 00:04:05 +0000 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!' 47141 vapier 2011-02-22 01:30:28 +0000 if you `ldd` that file, do you get the same error ? 47142 others 2011-02-22 01:53:27 +0000 (In reply to comment #11) > if you `ldd` that file, do you get the same error ? Yes, so no need to have prelink. 47143 carlos 2011-02-22 15:04:27 +0000 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. 47224 drepper.fsp 2011-02-25 21:52:13 +0000 I used Andreas's patch which in any case is OK. If this isn't the entire fix, reopen. 47229 cryptooctoploid 2011-02-26 07:40:18 +0000 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)?. 47468 jeff.chua.linux 2011-03-13 16:04:53 +0000 > 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 48373 jason.vas.dias 2011-04-25 19:59:58 +0000 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) 48379 jason.vas.dias 2011-04-26 13:20:13 +0000 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. 49048 drepper.fsp 2011-05-30 05:17:27 +0000 There is nothing to do here. If you apply patches which you've told are not acceptable and those are creating problems, then it is up to you to fix the patches you apply. 49052 vapier 2011-05-30 07:44:17 +0000 that isnt what is happening here. people are running unmodified git trees and hitting this nlist error. some people might be testing patches in an attempt to address the original problem, but those patches arent the cause. 49055 jason.vas.dias 2011-05-30 11:40:41 +0000 Sorry if my previous Comment #18 in any way deterred Ulrich from applying something like Kee's patch of Comment #4, which makes perfect sense to me and which is really needed to fix this bug - please, Ulrich, if you haven't already done so, apply something like attachment #5253 of Comment #4. What happened in my case was that I first compiled the unmodified glibc-2.13 in 32-bit mode, and noticed this problem, and others caused by the sub-arch loader not having an RPATH . So I applied my usual "allow RPATH on ld.so" patch and rebuilt, fixing some problems, but leaving this one, which occurs when using any non-native-system ld.so (NOT /lib/ld-linux.so.1) with '-nostdlibs' . 49056 jason.vas.dias 2011-05-30 12:02:23 +0000 typo in previous Comment #21: non-native-system ld.so (NOT /lib/ld-linux.so.1) with '-nostdlibs' should be : non-native-system ld.so (NOT /lib/ld-linux.so.2) with '-nostdlib' Anyway, I'm going to be compiling the latest glibc from GIT soon , after I build the latest stable Linux kernel, and will test with / without patch of attachment #5253 and post results . But Ulrich, please try : o build an installation from unmodified source in 32-bit mode with LIBDIR=/lib32 Then : $ echo 'int an_int = 1;' > t.c; gcc -m32 -o t.so -shared -nostdlib -fPIC t.c; ldd t.so Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! 49059 drepper.fsp 2011-05-30 16:35:48 +0000 I've added a patch. 50145 carlos 2011-08-04 13:09:05 +0000 Backported this to 2.13 stable branch. 5220 2011-01-30 21:58:00 +0000 2011-01-30 21:58:32 +0000 replace assert by if binutils2.patch text/plain 3123 cryptooctoploid ZGlmZiAtLWdpdCBhL2VsZi9kbC1kZXBzLmMgYi9lbGYvZGwtZGVwcy5jCmluZGV4IDQ0MGZiNTYu LmMyYWRlY2MgMTAwNjQ0Ci0tLSBhL2VsZi9kbC1kZXBzLmMKKysrIGIvZWxmL2RsLWRlcHMuYwpA QCAtNjE5LDU1ICs2MTksNTQgQEAgRmlsdGVycyBub3Qgc3VwcG9ydGVkIHdpdGggTERfVFJBQ0Vf UFJFTElOS0lORyIpKTsKIAogICAvKiBXZSBjYW4gc2tpcCBsb29raW5nIGZvciB0aGUgYmluYXJ5 IGl0c2VsZiB3aGljaCBpcyBhdCB0aGUgZnJvbnQKICAgICAgb2YgdGhlIHNlYXJjaCBsaXN0LiAg Ki8KLSAgYXNzZXJ0IChubGlzdCA+IDEpOwotICBpID0gMTsKLSAgYm9vbCBzZWVuW25saXN0XTsK LSAgbWVtc2V0IChzZWVuLCBmYWxzZSwgbmxpc3QgKiBzaXplb2YgKHNlZW5bMF0pKTsKLSAgd2hp bGUgKDEpCisgIGlmIChubGlzdCA+IDEpCiAgICAgewotICAgICAgLyogS2VlcCB0cmFjayBvZiB3 aGljaCBvYmplY3Qgd2UgbG9va2VkIGF0IHRoaXMgcm91bmQuICAqLwotICAgICAgc2VlbltpXSA9 IHRydWU7Ci0gICAgICBzdHJ1Y3QgbGlua19tYXAgKnRoaXNwID0gbF9pbml0ZmluaVtpXTsKLQot ICAgICAgLyogRmluZCB0aGUgbGFzdCBvYmplY3QgaW4gdGhlIGxpc3QgZm9yIHdoaWNoIHRoZSBj dXJyZW50IG9uZSBpcwotCSBhIGRlcGVuZGVuY3kgYW5kIG1vdmUgdGhlIGN1cnJlbnQgb2JqZWN0 IGJlaGluZCB0aGUgb2JqZWN0Ci0JIHdpdGggdGhlIGRlcGVuZGVuY3kuICAqLwotICAgICAgdW5z aWduZWQgaW50IGsgPSBubGlzdCAtIDE7Ci0gICAgICB3aGlsZSAoayA+IGkpCi0JewotCSAgc3Ry dWN0IGxpbmtfbWFwICoqcnVucCA9IGxfaW5pdGZpbmlba10tPmxfaW5pdGZpbmk7Ci0JICBpZiAo cnVucCAhPSBOVUxMKQotCSAgICAvKiBMb29rIHRocm91Z2ggdGhlIGRlcGVuZGVuY2llcyBvZiB0 aGUgb2JqZWN0LiAgKi8KLQkgICAgd2hpbGUgKCpydW5wICE9IE5VTEwpCi0JICAgICAgaWYgKF9f YnVpbHRpbl9leHBlY3QgKCpydW5wKysgPT0gdGhpc3AsIDApKQotCQl7Ci0JCSAgLyogTW92ZSB0 aGUgY3VycmVudCBvYmplY3QgdG8gdGhlIGJhY2sgcGFzdCB0aGUgbGFzdAotCQkgICAgIG9iamVj dCB3aXRoIGl0IGFzIHRoZSBkZXBlbmRlbmN5LiAgKi8KLQkJICBtZW1tb3ZlICgmbF9pbml0Zmlu aVtpXSwgJmxfaW5pdGZpbmlbaSArIDFdLAotCQkJICAgKGsgLSBpKSAqIHNpemVvZiAobF9pbml0 ZmluaVswXSkpOwotCQkgIGxfaW5pdGZpbmlba10gPSB0aGlzcDsKLQotCQkgIGlmIChzZWVuW2kg KyAxXSkKLQkJICAgIHsKLQkJICAgICAgKytpOwotCQkgICAgICBnb3RvIG5leHRfY2xlYXI7Ci0J CSAgICB9Ci0KLQkJICBtZW1tb3ZlICgmc2VlbltpXSwgJnNlZW5baSArIDFdLCAoayAtIGkpICog c2l6ZW9mIChzZWVuWzBdKSk7Ci0JCSAgc2VlbltrXSA9IHRydWU7Ci0KLQkJICBnb3RvIG5leHQ7 Ci0JCX0KLQotCSAgLS1rOwotCX0KKyAgICAgIGkgPSAxOworICAgICAgYm9vbCBzZWVuW25saXN0 XTsKKyAgICAgIG1lbXNldCAoc2VlbiwgZmFsc2UsIG5saXN0ICogc2l6ZW9mIChzZWVuWzBdKSk7 CisgICAgICB3aGlsZSAoMSkKKyAgICAgICAgeworICAgICAgICAgIC8qIEtlZXAgdHJhY2sgb2Yg d2hpY2ggb2JqZWN0IHdlIGxvb2tlZCBhdCB0aGlzIHJvdW5kLiAgKi8KKyAgICAgICAgICBzZWVu W2ldID0gdHJ1ZTsKKyAgICAgICAgICBzdHJ1Y3QgbGlua19tYXAgKnRoaXNwID0gbF9pbml0Zmlu aVtpXTsKKworICAgICAgICAgIC8qIEZpbmQgdGhlIGxhc3Qgb2JqZWN0IGluIHRoZSBsaXN0IGZv ciB3aGljaCB0aGUgY3VycmVudCBvbmUgaXMKKyAgICAgICAgICAgICBhIGRlcGVuZGVuY3kgYW5k IG1vdmUgdGhlIGN1cnJlbnQgb2JqZWN0IGJlaGluZCB0aGUgb2JqZWN0CisgICAgICAgICAgICAg d2l0aCB0aGUgZGVwZW5kZW5jeS4gICovCisgICAgICAgICAgdW5zaWduZWQgaW50IGsgPSBubGlz dCAtIDE7CisgICAgICAgICAgd2hpbGUgKGsgPiBpKQorICAgICAgICAgICAgeworICAgICAgICAg ICAgICBzdHJ1Y3QgbGlua19tYXAgKipydW5wID0gbF9pbml0ZmluaVtrXS0+bF9pbml0ZmluaTsK KyAgICAgICAgICAgICAgaWYgKHJ1bnAgIT0gTlVMTCkKKyAgICAgICAgICAgICAgLyogTG9vayB0 aHJvdWdoIHRoZSBkZXBlbmRlbmNpZXMgb2YgdGhlIG9iamVjdC4gICovCisgICAgICAgICAgICAg IHdoaWxlICgqcnVucCAhPSBOVUxMKQorICAgICAgICAgICAgICAgIGlmIChfX2J1aWx0aW5fZXhw ZWN0ICgqcnVucCsrID09IHRoaXNwLCAwKSkKKyAgICAgICAgICAgICAgICAgIHsKKwkJICAgIC8q IE1vdmUgdGhlIGN1cnJlbnQgb2JqZWN0IHRvIHRoZSBiYWNrIHBhc3QgdGhlIGxhc3QKKwkJICAg ICAgIG9iamVjdCB3aXRoIGl0IGFzIHRoZSBkZXBlbmRlbmN5LiAgKi8KKwkJICAgIG1lbW1vdmUg KCZsX2luaXRmaW5pW2ldLCAmbF9pbml0ZmluaVtpICsgMV0sCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoayAtIGkpICogc2l6ZW9mIChsX2luaXRmaW5pWzBdKSk7CisJCSAgICBsX2lu aXRmaW5pW2tdID0gdGhpc3A7CisKKwkJICAgIGlmIChzZWVuW2kgKyAxXSkKKwkJICAgICAgewor CQkgICAgICAgICsraTsKKwkJICAgICAgICBnb3RvIG5leHRfY2xlYXI7CisJCSAgICAgIH0KIAot ICAgICAgaWYgKCsraSA9PSBubGlzdCkKLQlicmVhazsKLSAgICBuZXh0X2NsZWFyOgotICAgICAg bWVtc2V0ICgmc2VlbltpXSwgZmFsc2UsIChubGlzdCAtIGkpICogc2l6ZW9mIChzZWVuWzBdKSk7 CisJCSAgICBtZW1tb3ZlICgmc2VlbltpXSwgJnNlZW5baSArIDFdLCAoayAtIGkpICogc2l6ZW9m IChzZWVuWzBdKSk7CisJCSAgICBzZWVuW2tdID0gdHJ1ZTsKIAotICAgIG5leHQ6OworCQkgICAg Z290byBuZXh0OworCQkgIH0KKwkgICAgICAtLWs7CisgICAgICAgICAgICB9CisgICAgICAgICAg aWYgKCsraSA9PSBubGlzdCkKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICAgIG5leHRfY2xl YXI6CisgICAgICAgICAgICBtZW1zZXQgKCZzZWVuW2ldLCBmYWxzZSwgKG5saXN0IC0gaSkgKiBz aXplb2YgKHNlZW5bMF0pKTsKKyAgICAgICAgICBuZXh0OjsKKyAgICAgICAgfQogICAgIH0KIAog ICAvKiBUZXJtaW5hdGUgdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVzLiAgKi8K 5229 2011-02-05 19:43:00 +0000 2011-02-05 19:43:28 +0000 Don't call _dl_sort_fini if there is only one object. (part 2) glibc_nlist_fini.patch text/plain 427 cryptooctoploid ZGlmZiAtLWdpdCBhL2VsZi9kbC1jbG9zZS5jIGIvZWxmL2RsLWNsb3NlLmMKaW5kZXggZjZkOGRk My4uMTEyYzE2YyAxMDA2NDQKLS0tIGEvZWxmL2RsLWNsb3NlLmMKKysrIGIvZWxmL2RsLWNsb3Nl LmMKQEAgLTIyMiw3ICsyMjIsOCBAQCBfZGxfY2xvc2Vfd29ya2VyIChzdHJ1Y3QgbGlua19tYXAg Km1hcCkKICAgICB9CiAKICAgLyogU29ydCB0aGUgZW50cmllcy4gICovCi0gIF9kbF9zb3J0X2Zp bmkgKG5zLT5fbnNfbG9hZGVkLCBtYXBzLCBubG9hZGVkLCB1c2VkLCBuc2lkKTsKKyAgaWYgKG5s b2FkZWQgPiAxKQorICAgIF9kbF9zb3J0X2ZpbmkgKG5zLT5fbnNfbG9hZGVkLCBtYXBzLCBubG9h ZGVkLCB1c2VkLCBuc2lkKTsKIAogICAvKiBDYWxsIGFsbCB0ZXJtaW5hdGlvbiBmdW5jdGlvbnMg YXQgb25jZS4gICovCiAjaWZkZWYgU0hBUkVECg== 5253 2011-02-18 23:49:00 +0000 2011-02-18 23:49:21 +0000 combined fixes pr12454.diff text/plain 917 kees SW5kZXg6IGIvZWxmL2RsLWNsb3NlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYS9lbGYvZGwtY2xvc2UuYwor KysgYi9lbGYvZGwtY2xvc2UuYwpAQCAtMjIyLDcgKzIyMiw4IEBACiAgICAgfQogCiAgIC8qIFNv cnQgdGhlIGVudHJpZXMuICAqLwotICBfZGxfc29ydF9maW5pIChucy0+X25zX2xvYWRlZCwgbWFw cywgbmxvYWRlZCwgdXNlZCwgbnNpZCk7CisgIGlmIChubG9hZGVkID4gMSkKKyAgICBfZGxfc29y dF9maW5pIChucy0+X25zX2xvYWRlZCwgbWFwcywgbmxvYWRlZCwgdXNlZCwgbnNpZCk7CiAKICAg LyogQ2FsbCBhbGwgdGVybWluYXRpb24gZnVuY3Rpb25zIGF0IG9uY2UuICAqLwogI2lmZGVmIFNI QVJFRApJbmRleDogYi9lbGYvZGwtZGVwcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGEvZWxmL2RsLWRlcHMu YworKysgYi9lbGYvZGwtZGVwcy5jCkBAIC02MTksMTEgKzYxOSwxMSBAQAogCiAgIC8qIFdlIGNh biBza2lwIGxvb2tpbmcgZm9yIHRoZSBiaW5hcnkgaXRzZWxmIHdoaWNoIGlzIGF0IHRoZSBmcm9u dAogICAgICBvZiB0aGUgc2VhcmNoIGxpc3QuICAqLwotICBhc3NlcnQgKG5saXN0ID4gMSk7Cisg IGFzc2VydCAobmxpc3QgPiAwKTsKICAgaSA9IDE7CiAgIGJvb2wgc2VlbltubGlzdF07CiAgIG1l bXNldCAoc2VlbiwgZmFsc2UsIG5saXN0ICogc2l6ZW9mIChzZWVuWzBdKSk7Ci0gIHdoaWxlICgx KQorICB3aGlsZSAobmxpc3QgPiAxKQogICAgIHsKICAgICAgIC8qIEtlZXAgdHJhY2sgb2Ygd2hp Y2ggb2JqZWN0IHdlIGxvb2tlZCBhdCB0aGlzIHJvdW5kLiAgKi8KICAgICAgIHNlZW5baV0gPSB0 cnVlOwo=