[oe-commits] [openembedded-core] 11/11: uninative: Handle futex hangs caused by glibc version mismatches

[git at git.openembedded.org]

This is an automated email from the git hooks/post-receive script.

rpurdie pushed a commit to branch morty-next
in repository openembedded-core.

commit fb9b45560c8d8ed88be7e56932fb24e41e65ba08
Author: Richard Purdie <richard.purdie at linuxfoundation.org>
AuthorDate: Fri Dec 8 15:14:31 2017 +0000

    uninative: Handle futex hangs caused by glibc version mismatches
    
    We've been seeing hangs in smart on the autobuilders where it hangs in
    pthread futex calls. It appears to happen when some components are
    installed from sstate (which use the interpreter from uninative)
    and other components are built natively (and use the host's interpreter).
    
    Its primarily affecting software which uses shared memory with futexs in
    for locking purposes (which bdb does called from librpm from smart).
    
    This isn't an issue in pyro and rocko and beyond since they use recipe
    specific sysroots which included a change to always change to the
    uninative interpreter. We could backport those changes but they're
    fairly invasive changes to the sstate code. This patch is a more
    minimal change which ensures binaries are always using the uninative
    interpreter regardless of whether they're built locally or installed
    from sstate.
    
    This is only an issue if you're using an sstate mirror and hosts
    with a variety of different libc versions. It has only become an issue
    on recent libc versions where there was clearly some forwards compatibility
    issue introduced.
    
    Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
---
 meta/classes/uninative.bbclass | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 9754669..241ca74 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -91,6 +91,7 @@ def enable_uninative(d):
         bb.debug(2, "Enabling uninative")
         d.setVar("NATIVELSBSTRING", "universal%s" % oe.utils.host_gcc_version(d))
         d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
+        d.setVar("EXTRAINSTALLFUNCS_class-native", "uninative_relocate")
         d.prependVar("PATH", "${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:")
 
 python uninative_changeinterp () {
@@ -128,3 +129,20 @@ python uninative_changeinterp () {
                 bb.fatal("'%s' failed with exit code %d and the following output:\n%s" %
                          (e.cmd, e.returncode, e.output))
 }
+
+# In morty we have a problem since files can come from sstate or be built locally. Mixing interpreters
+# for local vs. sstate objects can result in hard to debug futex hangs in shared memory regions (e.g.
+# from smart/rpm/libdb).
+# To resolve this, relocate natively build binaries too. This fix isn't needed post morty since RSS
+# always uses uninative interpreter manipulations for code path simplicity.
+EXTRAINSTALLFUNCS = ""
+do_install[vardepsexclude] = "uninative_relocate"
+do_install[postfuncs] += "${EXTRAINSTALLFUNCS}"
+
+python uninative_relocate () {
+    # (re)Use uninative_changeinterp() to change the interpreter in files in ${D}
+    orig = d.getVar('SSTATE_INSTDIR', False)
+    d.setVar('SSTATE_INSTDIR', "${D}")
+    bb.build.exec_func("uninative_changeinterp", d)
+    d.setVar('SSTATE_INSTDIR', orig)
+}

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.