[Bug runtime/22031] New: failure in pthread_stacks.exp

[Bug runtime/22031] New: failure in pthread_stacks.exp

[dsmith at redhat dot com]

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

            Bug ID: 22031
           Summary: failure in pthread_stacks.exp
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

The systemtap.base/pthread_stacks.exp test case (which runs the
process/threadstacks.stp example) is getting a new failure since the bpf merge:

    FAIL: pthread_stacks -Gsize (1 0)

This failure is consistent on 4.12.5-300.fc26.i686+PAE, 2.6.32-696.el6.x86_64
and 3.10.0-693.el7.ppc64le. If you look at the systemtap.log file, you'll see
this (this example is from 3.10.0-693.el7.ppc64le):

====
ERROR: read fault [man error::fault] at 0x344b8 near identifier
'$__default_pthread_attr' at
/root/src.copy/testsuite/systemtap.examples/process/threadstacks.stp:24:11
====

That address doesn't look reasonable.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/22031] failure in pthread_stacks.exp

[dsmith at redhat dot com]

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

--- Comment #1 from David Smith <dsmith at redhat dot com> ---
In the current code, stap -p3 does the following to get the value of
$__default_pthread_attr:

  l->__retvalue = uderef(8, (((int64_t)214200LL)));

Using a pre-bpf stap, I see the following:

====
  {
    uintptr_t addr;
    { // DWARF expression: 0x3(214168)
      {
        uintptr_t s0;
        s0 = /* pragma:vma */({ unsigned long addr = 0; addr =
_stp_umodule_relocate ("/usr/lib64/libpthread-2.17.so",0x34498, current); addr;
});
        addr = s0;
      }
    }
    { // DWARF expression: 0x23(32)
      {
        uintptr_t s0;
        s0 = addr;
        s0 = s0 + 32UL;
        addr = s0;
      }
    }
    { uint64_t value = deref (8, addr); STAP_RETVALUE = value; }
====

It looks like the current code forgot to relocate the module. They are both
trying to read the same offset, just the pre-bpf code relocates libpthread
first.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/22031] failure in pthread_stacks.exp

[dsmith at redhat dot com]

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from David Smith <dsmith at redhat dot com> ---
Fixed in commit 9d083c7df.

(Note that the test still fails on 4.5.0-15.4.2.el7.aarch64, but the pre-bpf
code failed here in the exact same way, with an assert that pthread_create()
failed.)

-- 
You are receiving this mail because:
You are the assignee for the bug.