This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 0.161 elfutils test are failing on Linux Arch

Hi Anatol,

On Wed, 2015-01-14 at 13:30 -0800, Anatol Pomozov wrote:
> On Wed, Jan 14, 2015 at 1:16 PM, Mark Wielaard <> 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
> has.
> 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

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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]