[Bug translator/11735] New: similarly named executables/libraries get probed/detected wrongly

[Bug translator/11735] New: similarly named executables/libraries get probed/detected wrongly

[mjw at redhat dot com]

While fixing bug #11722 I noticed that unless we rename the
executables/libraries under test the symbol resolution goes wrong when there are
multiple architectures (64/32 bit) tested. The testcase got rewritten to work
around this issue. But we need to figure out why that fails.

-- 
           Summary: similarly named executables/libraries get
                    probed/detected wrongly
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11735

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

[Bug translator/11735] similarly named executables/libraries get probed/detected wrongly

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-06-21 12:03 -------
This is the workaround commit:

commit 2c8f96fd9f13f1d7a5c6efeb7ad4f7760026c743
Author: Mark Wielaard <mjw@redhat.com>
Date:   Mon Jun 21 13:57:16 2010 +0200

    Rework usymbols.exp to create arch specific executables and library names.
    
    This makes it more clear what setup is specifically tested. But it also
    seems to work around a bug where systemtap apparently picks up the wrong
    copy (cached?) of similarly named executables/shared libraries. PR11735.
    
    * testsuite/systemtap.context/usymbols.exp: Make testexename/testlibname
      derived from arch under test.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11735

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

[Bug translator/11735] similarly named executables/libraries get probed/detected wrongly

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-06-21 12:34 -------
After commit 23c2d7 [PR11722 user_long(uaddr) should fetch a user space long (in
case of 32-on-64)] make installcheck RUNTESTFLAGS=usymbols.exp should PASS on
x86_64.

But if you revert commit 2c8f96 from comment #1 it actually fails:

Host: Linux springer.wildebeest.org 2.6.32-36.el6.x86_64 #1 SMP Wed Jun 16
15:48:48 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Snapshot: version 1.2/0.147 commit release-1.2-298-g23c2d7d + changes
GCC: 4.4.4 [gcc (GCC) 4.4.4 20100611 (Red Hat 4.4.4-8)]
Distro: Red Hat Enterprise Linux release 6.0 Beta (Santiago)

Running /usr/local/src/systemtap/testsuite/systemtap.context/usymbols.exp ...
FAIL: usymbols -m32

		=== systemtap Summary ===

# of expected passes		1
# of unexpected failures	1


End of testsuite/systemtap.log:

Executing on host: gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols_lib.c  -fPIC
-shared  -lm   -o /usr/local/build/systemtap-obj/testsuite/libusymbols.so   
(timeout = 300)
spawn -ignore SIGHUP gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols_lib.c -fPIC
-shared -lm -o /usr/local/build/systemtap-obj/testsuite/libusymbols.so
Executing on host: gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols.c  -g -O
-L/usr/local/build/systemtap-obj/testsuite -lusymbols
-Wl,-rpath,/usr/local/build/systemtap-obj/testsuite  -lm   -o
/usr/local/build/systemtap-obj/testsuite/usymbols    (timeout = 300)
spawn -ignore SIGHUP gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols.c -g -O
-L/usr/local/build/systemtap-obj/testsuite -lusymbols
-Wl,-rpath,/usr/local/build/systemtap-obj/testsuite -lm -o
/usr/local/build/systemtap-obj/testsuite/usymbols
cmd: stap -w -d /usr/local/build/systemtap-obj/testsuite/usymbols --ldd -c
/usr/local/build/systemtap-obj/testsuite/usymbols -e $script
cmd output: handler: main_handler (usymbols)
handler: lib_handler (libusymbols.so)
PASS: usymbols default
Executing on host: gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols_lib.c  -fPIC
-shared -m32  -lm   -o /usr/local/build/systemtap-obj/testsuite/libusymbols.so 
  (timeout = 300)
spawn -ignore SIGHUP gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols_lib.c -fPIC
-shared -m32 -lm -o /usr/local/build/systemtap-obj/testsuite/libusymbols.so
Executing on host: gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols.c  -g -O
-L/usr/local/build/systemtap-obj/testsuite -lusymbols
-Wl,-rpath,/usr/local/build/systemtap-obj/testsuite -m32  -lm   -o
/usr/local/build/systemtap-obj/testsuite/usymbols    (timeout = 300)
spawn -ignore SIGHUP gcc
/usr/local/src/systemtap/testsuite/systemtap.context/usymbols.c -g -O
-L/usr/local/build/systemtap-obj/testsuite -lusymbols
-Wl,-rpath,/usr/local/build/systemtap-obj/testsuite -m32 -lm -o
/usr/local/build/systemtap-obj/testsuite/usymbols
cmd: stap -w -d /usr/local/build/systemtap-obj/testsuite/usymbols --ldd -c
/usr/local/build/systemtap-obj/testsuite/usymbols -e $script
cmd output: handler: dtor_idx.6340 (usymbols)
handler: 0x00000000007e944c (libusymbols.so)
FAIL: usymbols -m32
line 1: expected "handler: main_handler (usymbols)", Got "handler: dtor_idx.6340
(usymbols)"


Note how it looks like the second -m32 testcase is using the symbol tables from
the default (64bit) testcase executables. How can that be?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11735

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

[Bug translator/11735] similarly named executables/libraries get probed/detected wrongly

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-06-21 13:11 -------
See also bug #9937

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11735

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

[Bug translator/11735] similarly named executables/libraries get probed/detected wrongly

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11735

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jistone at redhat dot com
         Resolution|                            |FIXED

--- Comment #4 from Josh Stone <jistone at redhat dot com> 2010-11-16 02:23:36 UTC ---
2ccb419 PR11735: Hash unwindsym_modules as full paths
d13bcfd PR11735: Hash ldd/vdso unwindsym_modules too

The change to using add_path means that the size and modification date are now
part of the hashing algorithm.  That's not quite as good as a build-id
(PR12221), but I think it will be practically good enough.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.