summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2017-12-08 15:14:31 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2017-12-11 21:47:28 +0000
commit590ef99df74581e6b7595e545c12594012653de8 (patch)
tree8bf83331dada639d22f21953a67784ca438344a2
parentef888dd58f431866db2472753643f3f848fece21 (diff)
downloadpoky-590ef99df74581e6b7595e545c12594012653de8.tar.gz
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. (From OE-Core rev: 6b149a88cd33c65c7f306f785f4d24ee2909809c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r--meta/classes/uninative.bbclass18
1 files changed, 18 insertions, 0 deletions
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 9754669296..241ca742e6 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -91,6 +91,7 @@ def enable_uninative(d):
91 bb.debug(2, "Enabling uninative") 91 bb.debug(2, "Enabling uninative")
92 d.setVar("NATIVELSBSTRING", "universal%s" % oe.utils.host_gcc_version(d)) 92 d.setVar("NATIVELSBSTRING", "universal%s" % oe.utils.host_gcc_version(d))
93 d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp") 93 d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
94 d.setVar("EXTRAINSTALLFUNCS_class-native", "uninative_relocate")
94 d.prependVar("PATH", "${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:") 95 d.prependVar("PATH", "${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:")
95 96
96python uninative_changeinterp () { 97python uninative_changeinterp () {
@@ -128,3 +129,20 @@ python uninative_changeinterp () {
128 bb.fatal("'%s' failed with exit code %d and the following output:\n%s" % 129 bb.fatal("'%s' failed with exit code %d and the following output:\n%s" %
129 (e.cmd, e.returncode, e.output)) 130 (e.cmd, e.returncode, e.output))
130} 131}
132
133# In morty we have a problem since files can come from sstate or be built locally. Mixing interpreters
134# for local vs. sstate objects can result in hard to debug futex hangs in shared memory regions (e.g.
135# from smart/rpm/libdb).
136# To resolve this, relocate natively build binaries too. This fix isn't needed post morty since RSS
137# always uses uninative interpreter manipulations for code path simplicity.
138EXTRAINSTALLFUNCS = ""
139do_install[vardepsexclude] = "uninative_relocate"
140do_install[postfuncs] += "${EXTRAINSTALLFUNCS}"
141
142python uninative_relocate () {
143 # (re)Use uninative_changeinterp() to change the interpreter in files in ${D}
144 orig = d.getVar('SSTATE_INSTDIR', False)
145 d.setVar('SSTATE_INSTDIR', "${D}")
146 bb.build.exec_func("uninative_changeinterp", d)
147 d.setVar('SSTATE_INSTDIR', orig)
148}