[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in 0.174 release

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

Martin Liska  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #6 from Martin Liska  ---
I've just played with that and I did an error: one can't utilize ptrace and
open an executable in gdb. That causes the EPERM errno.
So the issue is still valid in my opinion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

Martin Liska  changed:

   What|Removed |Added

Summary|TEST|TEST
   |./tests/backtrace-dwarf |./tests/backtrace-dwarf
   |fails on s390x in 0.174 |fails on s390x in at least
   |release |0.173

--- Comment #7 from Martin Liska  ---
Note that it's not related to 0.174. I can see it also in 0.173, so as Mark
mentioned it's dependent on glibc, bintuils, ..

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[ldv at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #8 from Dmitry V. Levin  ---
If a process is not being traced and PTRACE_TRACEME fails with EPERM, then it
must be a kernel issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #9 from Martin Liska  ---
Hm, on x86_64 (on trunk) I see all tests OK, but:

$ ./backtrace-dwarf 
backtrace-dwarf: backtrace-dwarf.c:146: main: Assertion `errno == 0' failed.
0x77a4f08b  raise
0x77a384e9  abort
0x77a383c1  __assert_fail_base.cold.0
0x77a476f2  __assert_fail
0x40135amain

which should not happen. On my machine I see errno == 2.

I would expect the test will fail with:

diff --git a/tests/backtrace-dwarf.c b/tests/backtrace-dwarf.c
index e1eb4928..273d2b5e 100644
--- a/tests/backtrace-dwarf.c
+++ b/tests/backtrace-dwarf.c
@@ -143,8 +143,8 @@ main (int argc __attribute__ ((unused)), char **argv)
   abort ();
 case 0:;
   long l = ptrace (PTRACE_TRACEME, 0, NULL, NULL);
-  assert (errno == 0);
-  assert (l == 0);
+  if (errno != 0 || l != 0)
+return -1;
   cleanup_13_main ();
   abort ();
 default:

but it's still fine, while:
./backtrace-dwarf 
backtrace-dwarf: backtrace-dwarf.c:159: main: Assertion `WIFSTOPPED (status)'
failed.
Aborted (core dumped)

That said, the tests looks to me very fragile..

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[ldv at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

Dmitry V. Levin  changed:

   What|Removed |Added

 CC||ldv at sourceware dot org

--- Comment #10 from Dmitry V. Levin  ---
I'd suggest the following change to enhance error diagnostics:

diff --git a/tests/backtrace-dwarf.c b/tests/backtrace-dwarf.c
index 35f25ed6..3a22db31 100644
--- a/tests/backtrace-dwarf.c
+++ b/tests/backtrace-dwarf.c
@@ -143,9 +143,8 @@ main (int argc __attribute__ ((unused)), char **argv)
 case -1:
   abort ();
 case 0:;
-  long l = ptrace (PTRACE_TRACEME, 0, NULL, NULL);
-  assert (errno == 0);
-  assert (l == 0);
+  if (ptrace (PTRACE_TRACEME, 0, NULL, NULL))
+_exit(errno ?: -1);
   cleanup_13_main ();
   abort ();
 default:
@@ -155,10 +154,12 @@ main (int argc __attribute__ ((unused)), char **argv)
   errno = 0;
   int status;
   pid_t got = waitpid (pid, &status, 0);
-  assert (errno == 0);
-  assert (got == pid);
-  assert (WIFSTOPPED (status));
-  assert (WSTOPSIG (status) == SIGABRT);
+  if (got != pid)
+error (1, errno, "waitpid returned %d", got);
+  if (!WIFSTOPPED (status))
+error (1, 0, "unexpected wait status %u", status);
+  if (WSTOPSIG (status) != SIGABRT)
+error (1, 0, "unexpected signal %u", WSTOPSIG (status));

   Dwfl *dwfl = pid_to_dwfl (pid);
   dwfl_getthreads (dwfl, thread_callback, NULL);

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #11 from Martin Liska  ---
With the suggested patch I see following in test-suite.log on s390x:

[   86s] + cat tests/test-suite.log
[   86s] ==
[   86s]elfutils 0.174: tests/test-suite.log
[   86s] ==
[   86s] 
[   86s] # TOTAL: 202
[   86s] # PASS:  194
[   86s] # SKIP:  7
[   86s] # XFAIL: 0
[   86s] # FAIL:  1
[   86s] # XPASS: 0
[   86s] # ERROR: 0
[   86s] 
[   86s] .. contents:: :depth: 2
[   86s] 
[   86s] SKIP: run-addr2line-i-demangle-test.sh
[   86s] ==
[   86s] 
[   86s] demangler unsupported
[   86s] SKIP run-addr2line-i-demangle-test.sh (exit status: 77)
[   86s] 
[   86s] SKIP: run-backtrace-data.sh
[   86s] ===
[   86s] 
[   86s] /home/abuild/rpmbuild/BUILD/elfutils-0.174/tests/backtrace-data:
Unwinding not supported for this architecture
[   86s] data: arch not supported
[   86s] SKIP run-backtrace-data.sh (exit status: 77)
[   86s] 
[   86s] FAIL: run-backtrace-dwarf.sh
[   86s] 
[   86s] 
[   86s] 0x3ffbda40622  raise
[   86s] 0x3ffbda23ce2  abort
[   86s] /home/abuild/rpmbuild/BUILD/elfutils-0.174/tests/backtrace-dwarf:
dwfl_thread_getframes: no error
[   86s] dwarf: no main
[   86s] FAIL run-backtrace-dwarf.sh (exit status: 1)
[   86s] 
[   86s] SKIP: run-backtrace-native-core.sh
[   86s] ==
[   86s] 
[   86s] No core.12202 file generated
[   86s] SKIP run-backtrace-native-core.sh (exit status: 77)
[   86s] 
[   86s] SKIP: run-backtrace-native-core-biarch.sh
[   86s] =
[   86s] 
[   86s] No core.12218 file generated
[   86s] SKIP run-backtrace-native-core-biarch.sh (exit status: 77)
[   86s] 
[   86s] SKIP: run-backtrace-demangle.sh
[   86s] ===
[   86s] 
[   86s] demangler unsupported
[   86s] SKIP run-backtrace-demangle.sh (exit status: 77)
[   86s] 
[   86s] SKIP: run-stack-demangled-test.sh
[   86s] =
[   86s] 
[   86s] demangler unsupported
[   86s] SKIP run-stack-demangled-test.sh (exit status: 77)
[   86s] 
[   86s] SKIP: run-lfs-symbols.sh
[   86s] 
[   86s] 
[   86s] LFS testing is irrelevent on this system
[   86s] SKIP run-lfs-symbols.sh (exit status: 77)
[   86s]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[ldv at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #12 from Dmitry V. Levin  ---
(In reply to Martin Liska from comment #11)
> With the suggested patch I see following in test-suite.log on s390x:
[...]
> [   86s] FAIL: run-backtrace-dwarf.sh
> [   86s] 
> [   86s] 
> [   86s] 0x3ffbda40622raise
> [   86s] 0x3ffbda23ce2abort
> [   86s] /home/abuild/rpmbuild/BUILD/elfutils-0.174/tests/backtrace-dwarf:
> dwfl_thread_getframes: no error
> [   86s] dwarf: no main
> [   86s] FAIL run-backtrace-dwarf.sh (exit status: 1)

This doesn't look like a PTRACE_TRACEME failing with EPERM, abort() has
actually been invoked by the tracee.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #13 from Martin Liska  ---
(In reply to Dmitry V. Levin from comment #12)
> (In reply to Martin Liska from comment #11)
> > With the suggested patch I see following in test-suite.log on s390x:
> [...]
> > [   86s] FAIL: run-backtrace-dwarf.sh
> > [   86s] 
> > [   86s] 
> > [   86s] 0x3ffbda40622  raise
> > [   86s] 0x3ffbda23ce2  abort
> > [   86s] /home/abuild/rpmbuild/BUILD/elfutils-0.174/tests/backtrace-dwarf:
> > dwfl_thread_getframes: no error
> > [   86s] dwarf: no main
> > [   86s] FAIL run-backtrace-dwarf.sh (exit status: 1)
> 
> This doesn't look like a PTRACE_TRACEME failing with EPERM, abort() has
> actually been invoked by the tracee.

Agree with that, question is how to debug that. Any idea?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Handling pgoff in perf elf mmap/mmap2 elf info

[Christoph Sterz]

Hi,

I work on Hotspot[1] an opensource linux perf aggregator and visualizer.
For this we use perfparser[2], which in turn uses libdw for unwinding.

Recently, we found more and more perf trace-files to use the 'pgoff'
field [3].
This happens especially on newer distros, (arch, opensuse tumbleweed).

We suspect perf to offset its recording-addresses of mmapped
dsos/executables starting with a specific section, such that they denote
their pointers with this pg_offset parameter. (e.g. skipping a library's
header and setting pgoff to the headersize). Although we are not 100%
sure about this information.

The Function I am using here is:
extern Dwfl_Module *dwfl_report_elf (Dwfl *dwfl, const char *name,
                 const char *file_name, int fd,
                 GElf_Addr base, bool add_p_vaddr);

in the specific call I am doing is:

 Dwfl_Module *ret = dwfl_report_elf(
    m_dwfl, info.originalFileName.constData(),
   
info.localFile.absoluteFilePath().toLocal8Bit().constData(), -1,
    info.addr,
    false);

and I am wondering how to include the pgoff here.

Simply subtracting it from info.addr results in a lots of "address range
overlaps an existing module" errors, where I guess I subtracted too
much. I know pgoff is in bytes.
Tried adding the offset, also overlap errors.

Ignoring the offset results in errors where perfparser fails to find ELF
for instruction pointer addresses.

I would be happy to hear if anyone has experience unwinding with these
offsets.
Maybe there is a different function I should use reporting the elf.
Maybe even someone unwinded/parsed perf data before.

Thanks,

Christoph


[1] https://github.com/KDAB/hotspot
[2] http://code.qt.io/cgit/qt-creator/perfparser.git/
[3] sparse info at
http://man7.org/linux/man-pages/man2/perf_event_open.2.html

-- 
Christoph Sterz | christoph.st...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts




smime.p7s
Description: S/MIME Cryptographic Signature

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #14 from Mark Wielaard  ---
The test case does use assert and abort too much. How about we extend Dmitry's
patch to get rid of them all (the only abort that should be there is the one in
cleanup-13.c).

diff --git a/tests/backtrace-dwarf.c b/tests/backtrace-dwarf.c
index 35f25ed..498416f 100644
--- a/tests/backtrace-dwarf.c
+++ b/tests/backtrace-dwarf.c
@@ -16,7 +16,6 @@
along with this program.  If not, see .  */

 #include 
-#include 
 #include 
 #include 
 #include 
@@ -141,13 +140,18 @@ main (int argc __attribute__ ((unused)), char **argv)
   switch (pid)
   {
 case -1:
-  abort ();
+  perror ("fork failed");
+  exit (-1);
 case 0:;
   long l = ptrace (PTRACE_TRACEME, 0, NULL, NULL);
-  assert (errno == 0);
-  assert (l == 0);
+  if (l != 0)
+   {
+ perror ("PTRACE_TRACEME failed");
+ exit (-1);
+   }
   cleanup_13_main ();
-  abort ();
+  printf ("cleanup_13_main returned, impossible...\n");
+  exit (-1);
 default:
   break;
   }
@@ -155,16 +159,20 @@ main (int argc __attribute__ ((unused)), char **argv)
   errno = 0;
   int status;
   pid_t got = waitpid (pid, &status, 0);
-  assert (errno == 0);
-  assert (got == pid);
-  assert (WIFSTOPPED (status));
-  assert (WSTOPSIG (status) == SIGABRT);
+  if (got != pid)
+error (1, errno, "waitpid returned %d", got);
+  if (!WIFSTOPPED (status))
+error (1, 0, "unexpected wait status %u", status);
+  if (WSTOPSIG (status) != SIGABRT)
+error (1, 0, "unexpected signal %u", WSTOPSIG (status));

   Dwfl *dwfl = pid_to_dwfl (pid);
-  dwfl_getthreads (dwfl, thread_callback, NULL);
+  if (dwfl_getthreads (dwfl, thread_callback, NULL) == -1)
+error (1, 0, "dwfl_getthreads: %s", dwfl_errmsg (-1));

   /* There is an exit (0) call if we find the "main" frame,  */
-  error (1, 0, "dwfl_getthreads: %s", dwfl_errmsg (-1));
+  printf ("dwfl_getthreads returned, main not found\n");
+  exit (-1);
 }

 #endif /* ! __linux__ */

-- 
You are receiving this mail because:
You are on the CC list for the bug.