This is the mail archive of the
mailing list for the elfutils project.
Re: 0.161 elfutils test are failing on Linux Arch
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Thu, 15 Jan 2015 12:06:51 +0100
- Subject: Re: 0.161 elfutils test are failing on Linux Arch
On Wed, 2015-01-14 at 13:30 -0800, Anatol Pomozov wrote:
> On Wed, Jan 14, 2015 at 1:16 PM, Mark Wielaard <email@example.com> wrote:
> > You do seem to have yama and alternate selinux security module enabled
> > it seems. Make sure it doesn't deny ptrace/proc/mem.
> > Probably /proc/sys/kernel/yama/ptrace_scope should be set to zero.
> Thanks for your pointer. My computer has YAMA indeed. The default
> ptrace_scope value is YAMA_SCOPE_RELATIONAL (1) and it is what my computer
> I temporary disabled YAMA with
> # sudo sysctl kernel.yama.ptrace_scope=0
> and now tests are passed:
> Testsuite summary for elfutils 0.161
> # TOTAL: 129
> # PASS: 127
> # SKIP: 2
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
Awesome! BTW. Which architecture and what are the two SKIPPED tests?
> So what I (as a packager) suppose to do here? I doubt that YAMA will be
> disabled in the default kernel. Should I just ignore these test failures?
> Or maybe "make check" should ignore these 2 tests if YAMA enabled?
Lets see if we can change the tests first to allow proper introspection
in this case (which hopefully also helps in the selinux case). I think
for the vdsosyms test we can just fork a child process instead to look
at the vdso instead of picking a random process. Currently it does:
/* Take our parent as "arbitrary" process to inspect. */
pid_t pid = getppid();
And for the deleted test we can probably first call
prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0) to allow eu-stack -p
to get at the memory image of the deleted-lib.so.
I'll try to code something up and if you could test that, that would be
But... This is really workarounds for the testcases. Then we know the
functionality works as intended. Except when a real user uses the dwfl
attach library calls or eu-stack binary...
So we probably need to figure out how to really fix this. How do other
tools and libraries work? What if a user wants to see why firefox is
wonky and does a strace -p $(pidof firefox) or gstack $(pidof firefox).
Are those tools also broken by default on Arch? Or do they use some
other trick to work properly?