4843 2013-07-11 14:28:54 +0000 Issue with pseudo on 64-bit build host 2013-09-13 14:07:07 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration unspecified x86 Multiple RESOLVED FIXED Medium+ normal 1.5 1 erik.boto seebs bluelightning gary lpapp pab ross.burton seebs sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 34516 0 erik.boto 2013-07-11 14:28:54 +0000 In bitbake.conf FAKEROOTBASEENV is set to contain "PSEUDO_LIBDIR=${STAGING_BINDIR_NATIVE}/../lib/pseudo/lib" but on my buildhost libpseudo.so is in ${STAGING_BINDIR_NATIVE}/../lib/pseudo/lib64. For me this causes rpm:s that use qemu_run_binary() to do stuff during do_rootfs() (using post-install scripts) to fail, since ld.so can't find libpseudo.so it gives an error that contains "ERR" which package_rpm.bbclass rpm_log_check() picks up. The error is: ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. I got confused for a while since the command used in the post-install script worked ok in a devshell but not during do_rootfs(), but this is due to the fact that LD_LIBRARY_PATH in the devshell contains: "<mybuilddir>/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64" . So for devshells the environment is correctly set up. So in short: The PSEUDO_UNLOAD=1 in qemu.bbclass's qemu_run_binary() should make pseudo remove the variable before running qemu, but since the host's libpseudo isn't found LD_PRELOAD is not stripped of libpseudo.so and the command run "inside" qemu will also display an error which is picked up in the log sanity check. This has also been discussed a bit on oe-core mailing list, http://lists.openembedded.org/pipermail/openembedded-core/2013-June/080328.html. 34909 1 lpapp 2013-07-25 15:14:18 +0000 I can reproduce this issue on Arch 64 bit. Is there a known workaround to get over the issue for now? 34911 2 ross.burton 2013-07-25 15:16:27 +0000 ACCEPTED means that the assignee is actively working on it. Please don't set it for bugs that you are not the assignee of. 34936 3 seebs 2013-07-26 00:21:07 +0000 I should clarify a thing. It *should be* okay for PSEUDO_LIBDIR not to be the actual library directory. What happens is: No matter what the host's naming conventions are, pseudo picks some directory (.../pseudo), and then stores 32-bit libpseudo in .../pseudo/lib, and 64-bit in .../pseudo/lib64. However, 32-bit libpseudo doesn't necessarily exist on 64-bit hosts. We then store the name of just the base directory in PSEUDO_LIBDIR. When pseudo wants to set up its environment, it checks for PSEUDO_LIBDIR in LD_LIBRARY_PATH. If that's not present, or if there is no LD_LIBRARY_PATH, pseudo sets LD_LIBRARY_PATH to contain ${PSEUDO_LIBDIR}:${PSEUDO_LIBDIR}64. There *does* seem to be one way you could get past this: If you somehow managed to get LD_LIBRARY_PATH set to contain ${PSEUDO_LIBDIR}, but *not* to contain ${PSEUDO_LIBDIR}64, then pseudo wouldn't realize it needed to fix that up. But that shouldn't ever happen; either we remove all of those or we don't remove any of them. I've been trying to find a system on which I can reproduce this. I can confirm that we aren't seeing this problem on at least a handful of different 64-bit systems, including both systems with a lib32 where lib is 64-bit, and those with a lib64. 35696 4 gary 2013-08-16 12:13:57 +0000 It fails for me on Ubuntu 12.04/x86_64 - have you tried this host yet? Note: I can reproduce this error quite simply by building an image with 'systemd' in DISTRO_FEATURES. On x86_64 it fails with this error, in i386 host it succeeds. 35697 5 lpapp 2013-08-16 12:15:28 +0000 Gary, yes, I did. It would be nice to see any progress in here ... 35701 6 gary 2013-08-16 13:12:09 +0000 (In reply to comment #5) > Gary, yes, I did. > > It would be nice to see any progress in here ... I ran it on a pretty much virgin system install. Perhaps you have some support library installed that I don't have? Do you have the pseudo package 'ia32-libs' installed? 35703 7 lpapp 2013-08-16 13:13:44 +0000 I mean, it fails for me, too, on Ubuntu x86_64, 12.04. 35706 8 seebs 2013-08-16 14:16:08 +0000 I haven't been able to make it fail on a host which can correctly build 32-bit binaries. Ubuntu 12.04/x86_64 is one of my default test environments. There's one obvious shortcoming in the current setup, which is that the pseudo recipe tries to build a 32-bit libpseudo if and only if NO32LIBS is "0" *and* it can find a stubs-32.h, indicating that a 32-bit build is likely to succeed. But I'm not sure whether that's related to the failure case here. The obvious thing to do would be to set NO32LIBS to "0" and make sure you have 32-bit libraries/compiler available. If that "fixes" this, then we're down to the question of why this particular thing is needing to run a 32-bit binary for some people but doesn't seem to be for others. 35707 9 gary 2013-08-16 14:40:24 +0000 (In reply to comment #8) > I haven't been able to make it fail on a host which can correctly build > 32-bit binaries. Ubuntu 12.04/x86_64 is one of my default test environments. > > There's one obvious shortcoming in the current setup, which is that the > pseudo recipe tries to build a 32-bit libpseudo if and only if NO32LIBS is > "0" *and* it can find a stubs-32.h, indicating that a 32-bit build is likely > to succeed. But I'm not sure whether that's related to the failure case here. > > The obvious thing to do would be to set NO32LIBS to "0" and make sure you > have 32-bit libraries/compiler available. If that "fixes" this, then we're > down to the question of why this particular thing is needing to run a 32-bit > binary for some people but doesn't seem to be for others. One thing we can do is compare what's on my host vs what's on yours, since it fails for me but succeeds for you. If you could email me the packages you have installed, I can compare and experiment a bit. I'm not a Debian guru so I may not know the best way to get this list but 'sudo dpkg -l | grep ^ii' will work. You could also just attach the list to this bug if you want. 35714 10 seebs 2013-08-16 18:13:46 +0000 I have normally been running our locally-modified build system, so it may be I'm just out of sync with oe-core. Just to clarify, you're getting this with a stock oe-core, default local.conf, with DISTRO_FEATURES += " systemd" or the equivalent? 35717 11 gary 2013-08-16 21:51:02 +0000 (In reply to comment #10) > I have normally been running our locally-modified build system, so it may be > I'm just out of sync with oe-core. > > Just to clarify, you're getting this with a stock oe-core, default > local.conf, with > > DISTRO_FEATURES += " systemd" > > or the equivalent? Correct - I adjusted DISTRO_FEATURES (directly in poky.conf but I'm sure you could do it using _append) and built a stock image (core-image-minimal). The error happens every time on my x86_64 system. 35760 12 ross.burton 2013-08-20 09:43:13 +0000 As another data point to show how bizarre this problem is: I have a 64-bit build host (Debian 7) with no 32-bit compat libraries present. Suddenly I started getting this error with no obvious cause, and "fixed" it by building just ipkg instead of rpm and ipkg. A few weeks later I re-enabled rpms and it works fine... 35892 13 gary 2013-08-23 16:07:22 +0000 (In reply to comment #12) > As another data point to show how bizarre this problem is: I have a 64-bit > build host (Debian 7) with no 32-bit compat libraries present. Suddenly I > started getting this error with no obvious cause, and "fixed" it by building > just ipkg instead of rpm and ipkg. A few weeks later I re-enabled rpms and > it works fine... I'm not sure it has anything to do with the packaging - I only ever use ipk. I have two Ubuntu 12.04 systems here - it runs on one and fails on the other. I've made sure that they both have identical packages installed (to the tune of installing some 975 packages today to make them match!). Still fails on one but not the other. I'm *really* confused by this... 35910 14 1440 pab 2013-08-26 08:15:59 +0000 Created attachment 1440 Fix bug by checking incoming environment for PATCH_UNLOAD=1 This fixes the manifestation of the bug in my environment. See also http://patches.openembedded.org/patch/56589/ 35928 15 gary 2013-08-26 19:50:04 +0000 (In reply to comment #14) > Created attachment 1440 [details] > Fix bug by checking incoming environment for PATCH_UNLOAD=1 > > This fixes the manifestation of the bug in my environment. See also > http://patches.openembedded.org/patch/56589/ Verified that this patch solves my problems with building on Ubuntu 12.04/x86_64 36200 16 seebs 2013-09-03 15:29:29 +0000 D'oh! Very good catch -- I think the key thing is "checking the wrong environment". I have now changed my position from "I can't see how this could fail" to "I can't see how this could work". It's true that there's a memory leak; the historical explanation for this is "we know we are about to call exec(), so we don't care", but it may be better to clean it up. The one pending question I see: Obviously, in the execve case, we want to unload pseudo if PSEUDO_UNLOAD is in envp. But what if PSEUDO_UNLOAD was in *our* environment, previously, and is NOT in the provided envp? My intuition is to say that we probably want it unloaded anyway. So I think it should probably be checking both for a PSEUDO_UNLOAD= in envp, and for an existing set value of PSEUDO_UNLOAD. I'm going to ponder this a bit. Thanks a ton for figuring this one out. 36202 17 pab 2013-09-03 16:00:16 +0000 (In reply to comment #16) > D'oh! Very good catch -- I think the key thing is "checking the wrong > environment". > > I have now changed my position from "I can't see how this could fail" to "I > can't see how this could work". Yes. > It's true that there's a memory leak; the historical explanation for this is > "we know we are about to call exec(), so we don't care", but it may be > better to clean it up. I think so. > The one pending question I see: Obviously, in the execve case, we want to > unload pseudo if PSEUDO_UNLOAD is in envp. > > But what if PSEUDO_UNLOAD was in *our* environment, previously, and is NOT > in the provided envp? My intuition is to say that we probably want it > unloaded anyway. So I think it should probably be checking both for a > PSEUDO_UNLOAD= in envp, and for an existing set value of PSEUDO_UNLOAD. I'm > going to ponder this a bit. I believe the effect of the approach I took was to unload if PSEUDO_UNLOAD appeared in either the provided or current environment. It's not clear to me what would cause PSEUDO_UNLOAD to be meaningfully set in the current environment: PSEUDO_UNLOAD=1 psuedo no i am not root ? > Thanks a ton for figuring this one out. You're welcome. 36285 18 seebs 2013-09-04 19:32:51 +0000 So, this converted from "how did this sometimes fail?" to "how did this sometimes work?" I hate those, so I spent some time looking at it. In particular, I modified a local copy of pseudo to perform the extra check, and diagnose cases where PSEUDO_UNLOAD was in envp but the existing check came up empty, and then I made a program which called id using execve, and setting PSEUDO_UNLOAD in envp. Aaaand... it still worked, for me. So I studied it more. And I finally found out roughly what's up. First off: The pseudo client will act as though pseudo were disabled if you successfully cause it to get loaded when PSEUDO_UNLOAD is set to 1. So we might simply fail to notice the problems. Secondly, the behavior when dealing with an unload is to set everything else up in the environment... Then unset the LD_PRELOAD value, but leave the others there. Finally, a plausible explanation for why this is affecting some people and not others: $ pseudo bash -c "PSEUDO_UNLOAD=1 env" | grep LD_PRELOAD $ pseudo dash -c "PSEUDO_UNLOAD=1 env" | grep LD_PRELOAD LD_PRELOAD=libpseudo.so $ It turns out that, in bash, PSEUDO_UNLOAD is in the environment before execve() is called, and in dash, it's not. And that is probably the underlying quirk that was causing this to fire some of the time. 36292 19 pab 2013-09-04 19:53:28 +0000 (In reply to comment #18) > It turns out that, in bash, PSEUDO_UNLOAD is in the environment before > execve() is called, and in dash, it's not. And that is probably the > underlying quirk that was causing this to fire some of the time. Good work. Over the years I've developed the habit of reconfiguring vendor-supplied environments only when I absolutely cannot tolerate the defaults, instead adapting my habits and expectations to the local "standard". I don't redirect /bin/sh on Ubuntu from dash to bash, and your result explains why the original approach didn't work for me. 36673 20 bluelightning 2013-09-13 11:07:17 +0000 Fix now merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eb34e8d8cee816dc64ad7ffc0eaa8cdc9a04d5eb 36674 21 lpapp 2013-09-13 11:15:33 +0000 Well, thanks. 36685 22 erik.boto 2013-09-13 14:07:07 +0000 Super, thanks! 1440 2013-08-26 08:15:59 +0000 2013-08-26 08:15:59 +0000 Fix bug by checking incoming environment for PATCH_UNLOAD=1 0001-pseudo_has_unload-add-function.patch text/plain 5920 pab RnJvbSA5ODgzYTVjMzE2ZjllNWYwN2Y5NTAxNGU0MjAxY2Q4MWQwMDViYWIwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiAiUGV0ZXIgQS4gQmlnb3QiIDxwYWJAcGFiaWdvdC5jb20+CkRh dGU6IFN1biwgMjUgQXVnIDIwMTMgMTk6MjI6MDkgLTA1MDAKU3ViamVjdDogW1BBVENIXSBwc2V1 ZG9faGFzX3VubG9hZDogYWRkIGZ1bmN0aW9uCgpWYXJpb3VzIHdyYXBwZXJzIGNoZWNrZWQgZm9y IGEgbm9uLW51bGwgcHNldWRvX2dldF92YWx1ZSgiUFNFVURPX1VOTE9BRCIpIHRvCmRldGVybWlu ZSB3aGV0aGVyIHRoZSBlbnZpcm9ubWVudCBzaG91bGQgaW5jbHVkZSB0aGUgcHNldWRvIHZhcmlh Ymxlcy4gIE5vbmUKb2YgdGhvc2UgY2hlY2tzIGZyZWVkIHRoZSByZXR1cm5lZCB2YWx1ZSB3aGVu IGl0IHdhcyBub3QgbnVsbC4gIFRoZSBuZXcKY2hlY2sgZnVuY3Rpb24gZG9lcy4KClRoZSBuZXcg Y2hlY2sgZnVuY3Rpb24gYWxzbyBzZWVzIHdoZXRoZXIgUFNFVURPX1VOTE9BRCB3YXMgZGVmaW5l ZCBpbiB0aGUKZW52aXJvbm1lbnQgdGhhdCBzaG91bGQgYmUgdXNlZCBpbiB0aGUgd3JhcHBlZCBz eXN0ZW0gY2FsbC4gIFRoaXMgYWxsb3dzCnBrZ19wb3N0aW5zdCBzY3JpcHRzIHRvIHN0cmlwIG91 dCB0aGUgTERfUFJFTE9BRCBzZXR0aW5nLCBmb3IgZXhhbXBsZSBiZWZvcmUKaW52b2tpbmcgcWVt dSB0byBleGVjdXRlIGNvbW1hbmRzIGluIGFuIGVudmlyb25tZW50IHRoYXQgZG9lcyBub3QgaGF2 ZQpsaWJwc2V1ZG8uc28uCgpbWU9DVE8gIzQ4NDNdCgpVcHN0cmVhbS1TdGF0dXM6IFBlbmRpbmcK U2lnbmVkLW9mZi1ieTogUGV0ZXIgQS4gQmlnb3QgPHBhYkBwYWJpZ290LmNvbT4KLS0tCiBwb3J0 cy9jb21tb24vZ3V0cy9leGVjdi5jICAgICAgICAgICAgICB8ICAgIDIgKy0KIHBvcnRzL2NvbW1v bi9ndXRzL2V4ZWN2ZS5jICAgICAgICAgICAgIHwgICAgMiArLQogcG9ydHMvY29tbW9uL2d1dHMv ZXhlY3ZwLmMgICAgICAgICAgICAgfCAgICAyICstCiBwb3J0cy9jb21tb24vZ3V0cy9mb3JrLmMg ICAgICAgICAgICAgICB8ICAgIDIgKy0KIHBvcnRzL2xpbnV4L25ld2Nsb25lL3BzZXVkb193cmFw cGVycy5jIHwgICAgMiArLQogcG9ydHMvbGludXgvb2xkY2xvbmUvcHNldWRvX3dyYXBwZXJzLmMg fCAgICAyICstCiBwb3J0cy91bml4L2d1dHMvcG9wZW4uYyAgICAgICAgICAgICAgICB8ICAgIDIg Ky0KIHBvcnRzL3VuaXgvZ3V0cy9zeXN0ZW0uYyAgICAgICAgICAgICAgIHwgICAgMiArLQogcHNl dWRvLmggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAxICsKIHBzZXVkb191dGls LmMgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAyNyArKysrKysrKysrKysrKysrKysrKysr KysrKysKIDEwIGZpbGVzIGNoYW5nZWQsIDM2IGluc2VydGlvbnMoKyksIDggZGVsZXRpb25zKC0p CgpkaWZmIC0tZ2l0IGEvcG9ydHMvY29tbW9uL2d1dHMvZXhlY3YuYyBiL3BvcnRzL2NvbW1vbi9n dXRzL2V4ZWN2LmMKaW5kZXggNzYzZTFmOS4uM2UxZjgyMCAxMDA2NDQKLS0tIGEvcG9ydHMvY29t bW9uL2d1dHMvZXhlY3YuYworKysgYi9wb3J0cy9jb21tb24vZ3V0cy9leGVjdi5jCkBAIC0xOSw3 ICsxOSw3IEBACiAJfQogCiAJcHNldWRvX3NldHVwZW52KCk7Ci0JaWYgKHBzZXVkb19nZXRfdmFs dWUoIlBTRVVET19VTkxPQUQiKSkKKwlpZiAocHNldWRvX2hhc191bmxvYWQoTlVMTCkpCiAJCXBz ZXVkb19kcm9wZW52KCk7CiAKIAkvKiBpZiBleGVjKCkgZmFpbHMsIHdlIG1heSBlbmQgdXAgdGFr aW5nIHNpZ25hbHMgdW5leHBlY3RlZGx5Li4uCmRpZmYgLS1naXQgYS9wb3J0cy9jb21tb24vZ3V0 cy9leGVjdmUuYyBiL3BvcnRzL2NvbW1vbi9ndXRzL2V4ZWN2ZS5jCmluZGV4IGEwMDM2NTcuLmZm NmE0NGUgMTAwNjQ0Ci0tLSBhL3BvcnRzL2NvbW1vbi9ndXRzL2V4ZWN2ZS5jCisrKyBiL3BvcnRz L2NvbW1vbi9ndXRzL2V4ZWN2ZS5jCkBAIC0yMCw3ICsyMCw3IEBACiAgICAgICAgIH0KIAogCW5l d19lbnZpcm9uID0gcHNldWRvX3NldHVwZW52cChlbnZwKTsKLQlpZiAocHNldWRvX2dldF92YWx1 ZSgiUFNFVURPX1VOTE9BRCIpKQorCWlmIChwc2V1ZG9faGFzX3VubG9hZChuZXdfZW52aXJvbikp CiAJCW5ld19lbnZpcm9uID0gcHNldWRvX2Ryb3BlbnZwKG5ld19lbnZpcm9uKTsKIAogCS8qIGlm IGV4ZWMoKSBmYWlscywgd2UgbWF5IGVuZCB1cCB0YWtpbmcgc2lnbmFscyB1bmV4cGVjdGVkbHku Li4KZGlmZiAtLWdpdCBhL3BvcnRzL2NvbW1vbi9ndXRzL2V4ZWN2cC5jIGIvcG9ydHMvY29tbW9u L2d1dHMvZXhlY3ZwLmMKaW5kZXggNWU3NWJlNy4uMDQyNTNjMyAxMDA2NDQKLS0tIGEvcG9ydHMv Y29tbW9uL2d1dHMvZXhlY3ZwLmMKKysrIGIvcG9ydHMvY29tbW9uL2d1dHMvZXhlY3ZwLmMKQEAg LTIwLDcgKzIwLDcgQEAKICAgICAgICAgfQogCiAJcHNldWRvX3NldHVwZW52KCk7Ci0JaWYgKHBz ZXVkb19nZXRfdmFsdWUoIlBTRVVET19VTkxPQUQiKSkKKwlpZiAocHNldWRvX2hhc191bmxvYWQo TlVMTCkpCiAJCXBzZXVkb19kcm9wZW52KCk7CiAKIAkvKiBpZiBleGVjKCkgZmFpbHMsIHdlIG1h eSBlbmQgdXAgdGFraW5nIHNpZ25hbHMgdW5leHBlY3RlZGx5Li4uCmRpZmYgLS1naXQgYS9wb3J0 cy9jb21tb24vZ3V0cy9mb3JrLmMgYi9wb3J0cy9jb21tb24vZ3V0cy9mb3JrLmMKaW5kZXggZGY4 YWJkNy4uYmViZTNiMCAxMDA2NDQKLS0tIGEvcG9ydHMvY29tbW9uL2d1dHMvZm9yay5jCisrKyBi L3BvcnRzL2NvbW1vbi9ndXRzL2ZvcmsuYwpAQCAtMTIsNyArMTIsNyBAQAogCSAqLwogCWlmIChy YyA9PSAwKSB7CiAJCXBzZXVkb19zZXR1cGVudigpOwotCQlpZiAoIXBzZXVkb19nZXRfdmFsdWUo IlBTRVVET19VTkxPQUQiKSkgeworCQlpZiAoIXBzZXVkb19oYXNfdW5sb2FkKE5VTEwpKSB7CiAJ CQlwc2V1ZG9fcmVpbml0X2xpYnBzZXVkbygpOwogCQl9IGVsc2UgewogCQkJcHNldWRvX2Ryb3Bl bnYoKTsKZGlmZiAtLWdpdCBhL3BvcnRzL2xpbnV4L25ld2Nsb25lL3BzZXVkb193cmFwcGVycy5j IGIvcG9ydHMvbGludXgvbmV3Y2xvbmUvcHNldWRvX3dyYXBwZXJzLmMKaW5kZXggMDkyZTUzMi4u MWZjNmM1OSAxMDA2NDQKLS0tIGEvcG9ydHMvbGludXgvbmV3Y2xvbmUvcHNldWRvX3dyYXBwZXJz LmMKKysrIGIvcG9ydHMvbGludXgvbmV3Y2xvbmUvcHNldWRvX3dyYXBwZXJzLmMKQEAgLTI4LDcg KzI4LDcgQEAgaW50IHdyYXBfY2xvbmVfY2hpbGQodm9pZCAqYXJncykgewogCiAJaWYgKCEoZmxh Z3MgJiBDTE9ORV9WTSkpIHsKIAkJcHNldWRvX3NldHVwZW52KCk7Ci0JCWlmICghcHNldWRvX2dl dF92YWx1ZSgiUFNFVURPX1VOTE9BRCIpKSB7CisJCWlmICghcHNldWRvX2hhc191bmxvYWQoTlVM TCkpIHsKIAkJCXBzZXVkb19yZWluaXRfbGlicHNldWRvKCk7CiAJCX0gZWxzZSB7CiAJCQlwc2V1 ZG9fZHJvcGVudigpOwpkaWZmIC0tZ2l0IGEvcG9ydHMvbGludXgvb2xkY2xvbmUvcHNldWRvX3dy YXBwZXJzLmMgYi9wb3J0cy9saW51eC9vbGRjbG9uZS9wc2V1ZG9fd3JhcHBlcnMuYwppbmRleCBm MGE4ZWVjLi4xNzIwZGZiIDEwMDY0NAotLS0gYS9wb3J0cy9saW51eC9vbGRjbG9uZS9wc2V1ZG9f d3JhcHBlcnMuYworKysgYi9wb3J0cy9saW51eC9vbGRjbG9uZS9wc2V1ZG9fd3JhcHBlcnMuYwpA QCAtMjIsNyArMjIsNyBAQCBpbnQgd3JhcF9jbG9uZV9jaGlsZCh2b2lkICphcmdzKSB7CiAKIAlp ZiAoIShmbGFncyAmIENMT05FX1ZNKSkgewogCQlwc2V1ZG9fc2V0dXBlbnYoKTsKLQkJaWYgKCFw c2V1ZG9fZ2V0X3ZhbHVlKCJQU0VVRE9fVU5MT0FEIikpIHsKKwkJaWYgKCFwc2V1ZG9faGFzX3Vu bG9hZChOVUxMKSkgewogCQkJcHNldWRvX3JlaW5pdF9saWJwc2V1ZG8oKTsKIAkJfSBlbHNlIHsK IAkJCXBzZXVkb19kcm9wZW52KCk7CmRpZmYgLS1naXQgYS9wb3J0cy91bml4L2d1dHMvcG9wZW4u YyBiL3BvcnRzL3VuaXgvZ3V0cy9wb3Blbi5jCmluZGV4IDBjYTE2YjAuLjVkNDRjMGUgMTAwNjQ0 Ci0tLSBhL3BvcnRzL3VuaXgvZ3V0cy9wb3Blbi5jCisrKyBiL3BvcnRzL3VuaXgvZ3V0cy9wb3Bl bi5jCkBAIC05LDcgKzksNyBAQAogCSAqIGluIHdheXMgdGhhdCBhdm9pZCBvdXIgdXN1YWwgZW5m b3JjZW1lbnQgb2YgdGhlIGVudmlyb25tZW50LgogCSAqLwogCXBzZXVkb19zZXR1cGVudigpOwot CWlmIChwc2V1ZG9fZ2V0X3ZhbHVlKCJQU0VVRE9fVU5MT0FEIikpCisJaWYgKHBzZXVkb19oYXNf dW5sb2FkKE5VTEwpKQogCQlwc2V1ZG9fZHJvcGVudigpOwogCiAJcmMgPSByZWFsX3BvcGVuKGNv bW1hbmQsIG1vZGUpOwpkaWZmIC0tZ2l0IGEvcG9ydHMvdW5peC9ndXRzL3N5c3RlbS5jIGIvcG9y dHMvdW5peC9ndXRzL3N5c3RlbS5jCmluZGV4IDAyOGIzNzIuLjYzNTE1OTIgMTAwNjQ0Ci0tLSBh L3BvcnRzL3VuaXgvZ3V0cy9zeXN0ZW0uYworKysgYi9wb3J0cy91bml4L2d1dHMvc3lzdGVtLmMK QEAgLTksNyArOSw3IEBACiAJCXJldHVybiAxOwogCiAJcHNldWRvX3NldHVwZW52KCk7Ci0JaWYg KHBzZXVkb19nZXRfdmFsdWUoIlBTRVVET19VTkxPQUQiKSkKKwlpZiAocHNldWRvX2hhc191bmxv YWQoTlVMTCkpCiAJCXBzZXVkb19kcm9wZW52KCk7CiAKIAlyYyA9IHJlYWxfc3lzdGVtKGNvbW1h bmQpOwpkaWZmIC0tZ2l0IGEvcHNldWRvLmggYi9wc2V1ZG8uaAppbmRleCAxNWRmMTY0Li40Y2Uw NzM5IDEwMDY0NAotLS0gYS9wc2V1ZG8uaAorKysgYi9wc2V1ZG8uaApAQCAtMjgsNiArMjgsNyBA QCBleHRlcm4gdm9pZCBwc2V1ZG9faW5pdF9jbGllbnQodm9pZCk7CiB2b2lkIHBzZXVkb19kdW1w X2VudihjaGFyICoqZW52cCk7CiBpbnQgcHNldWRvX3NldF92YWx1ZShjb25zdCBjaGFyICprZXks IGNvbnN0IGNoYXIgKnZhbHVlKTsKIGNoYXIgKnBzZXVkb19nZXRfdmFsdWUoY29uc3QgY2hhciAq a2V5KTsKK2ludCBwc2V1ZG9faGFzX3VubG9hZChjaGFyICogY29uc3QgKmVudnApOwogCiAjaW5j bHVkZSAicHNldWRvX3RhYmxlcy5oIgogCmRpZmYgLS1naXQgYS9wc2V1ZG9fdXRpbC5jIGIvcHNl dWRvX3V0aWwuYwppbmRleCAwZDgwMDA4Li5lYjFiYTNmIDEwMDY0NAotLS0gYS9wc2V1ZG9fdXRp bC5jCisrKyBiL3BzZXVkb191dGlsLmMKQEAgLTk1LDYgKzk1LDMzIEBAIGR1bXBfZW52KGNoYXIg KiplbnZwKSB7CiB9CiAjZW5kaWYKIAoraW50Citwc2V1ZG9faGFzX3VubG9hZChjaGFyICogY29u c3QgKmVudnApIHsKKwlzdGF0aWMgY29uc3QgY2hhciB1bmxvYWRbXSA9ICJQU0VVRE9fVU5MT0FE IjsKKwlzdGF0aWMgc2l6ZV90IHVubG9hZF9sZW4gPSBzdHJsZW4odW5sb2FkKTsKKwlzaXplX3Qg aSA9IDA7CisKKwkvKiBJcyBpdCBpbiB0aGUgY2FsbGVyIGVudmlyb25tZW50PyAqLworCWlmIChO VUxMICE9IGdldGVudih1bmxvYWQpKQorCQlyZXR1cm4gMTsKKworCS8qIElzIGl0IGluIHRoZSBl bnZpcm9ubWVudCBjYWNoZT8gKi8KKwlpZiAocHNldWRvX3V0aWxfaW5pdHRlZCA9PSAtMSkKKwkJ cHNldWRvX2luaXRfdXRpbCgpOworCXdoaWxlIChwc2V1ZG9fZW52W2ldLmtleSAmJiBzdHJjbXAo cHNldWRvX2VudltpXS5rZXksIHVubG9hZCkpCisJICAgICAgICsraTsKKwlpZiAocHNldWRvX2Vu dltpXS5rZXkgJiYgcHNldWRvX2VudltpXS52YWx1ZSkKKwkJcmV0dXJuIDE7CisKKwkvKiBJcyBp dCBpbiB0aGUgb3BlcmF0aW9uYWwgZW52aXJvbm1lbnQ/ICovCisJd2hpbGUgKGVudnAgJiYgKmVu dnApIHsKKwkJaWYgKCghc3RybmNtcCgqZW52cCwgdW5sb2FkLCB1bmxvYWRfbGVuKSkgJiYgKCc9 JyA9PSAoKmVudnApW3VubG9hZF9sZW5dKSkKKwkJCXJldHVybiAxOworCQkrK2VudnA7CisJfQor CXJldHVybiAwOworfQorCiAvKiBDYWxsZXIgbXVzdCBmcmVlIG1lbW9yeSEgKi8KIGNoYXIgKgog cHNldWRvX2dldF92YWx1ZShjb25zdCBjaGFyICprZXkpIHsKLS0gCjEuNy45LjUKCg==