Bug 510764 - Data dissapearing from print_backtrace on s390x between versions
Data dissapearing from print_backtrace on s390x between versions
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: systemtap (Show other bugs)
5.6
s390x Linux
medium Severity medium
: rc
: ---
Assigned To: Frank Ch. Eigler
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-10 12:34 EDT by Petr Muller
Modified: 2016-09-19 22:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-12 15:54:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Muller 2009-07-10 12:34:23 EDT
Description of problem:
On s390x, the testcase from bug 503225 showed a minor issue where a data displayed by an old version of systemtap were not displayed by a new version, which is actually a very minor regression. 

Version-Release number of selected component (if applicable):
0.9.7-5.el5
kernel-2.6.18-156.el5

How reproducible:
Always

Steps to Reproduce:
1. run the reproducer
2. see the backtrace
  
Actual results:
tcp_nagle_check time_us=1247234364123187 pid=31956 exec=sshd mss_now=1348 nonagle=1
 0x00000000002188a2 : __tcp_push_pending_frames+0x656/0x8cc [kernel]               
[0x0000000018a73a58] [0x0000000018a73a70] 0x0000000018a73a70  

Expected results:
tcp_nagle_check time_us=1247234271692047 pid=31956 exec=sshd mss_now=1348 nonagle=1             
 0x00000000002188a2 : __tcp_push_pending_frames+0x656/0x8cc [kernel]                            
[0x0000000018a73a58] [0x0000000018a73a70] 0x0000000018a73a70 : iucv_init+0x186b1838/0x0 [kernel]

Additional info:
the testcase:

global cur_mss, nonagle

probe kernel.function("tcp_snd_test").call,
      kernel.function("__tcp_push_pending_frames").call
{
    cur_mss[tid()]=$cur_mss;
    nonagle[tid()]=$nonagle ;
}



probe kernel.function("tcp_snd_test").return,
      kernel.function("__tcp_push_pending_frames").return
{
    delete cur_mss[tid()];
    delete nonagle[tid()] ;
}



probe kernel.function("tcp_nagle_check")
{
    if(isinstr(execname(), "ssh"))
    {
        printf("tcp_nagle_check time_us=%d pid=%5d exec=%s mss_now=%d nonagle=%d\n", gettimeofday_us(), pid(), execname(), cur_mss[tid()],
nonagle[tid()]);
print_backtrace();
    }
}
Comment 1 Mark Wielaard 2009-07-10 13:35:52 EDT
(In reply to comment #0)
> On s390x, the testcase from bug 503225 showed a minor issue where a data
> displayed by an old version of systemtap were not displayed by a new version,
> which is actually a very minor regression. 

Do you happen to have the version number of that old version of systemtap (and preferably also the kernel version)?
Comment 2 Petr Muller 2009-07-12 18:59:54 EDT
Sure.

I've already given a kernel version :) - kernel-2.6.18-156.el5

Sorry for not giving the exact versions - I sometimes tend to suffer from the Curse of Knowledge in the RHEL world...

The old version is RHEL5.3.z's systemtap, that means systemtap-0.7.2-3.el5_3
Comment 3 Mark Wielaard 2009-07-17 07:38:54 EDT
I cannot immediately find what could have changed here and don't have a s390x handy. The symbol lookup code did change somewhat since then, but for this case should be similar. The code that doesn't find the name is in runtime/sym.c:

static void _stp_symbol_print(unsigned long address)
{
        const char *modname;
        const char *name;
        unsigned long offset, size;

        name = _stp_kallsyms_lookup(address, &size, &offset, &modname, NULL, NULL);

        _stp_printf("%p", (int64_t) address);

        if (name) {
                if (modname && *modname)
                        _stp_printf(" : %s+%#lx/%#lx [%s]", name, offset, size, modname);
                else
                        _stp_printf(" : %s+%#lx/%#lx", name, offset, size);
        }
}

So _stp_kallsyms_lookup () failed for the given address. If the kernel version between the runs is the same I cannot really explain atm why that would be though.
Comment 4 Frank Ch. Eigler 2009-10-27 09:28:44 EDT
Sorry, we don't have a complete analysis/patch for this problem yet.
Comment 5 Frank Ch. Eigler 2010-01-06 19:32:37 EST
Need to reassess to what extent the 1.0.9 code for rhel5.5 improves this; otherwise defer.
Comment 6 Frank Ch. Eigler 2010-07-12 15:40:14 EDT
We cannot promise fixing this one in time, but the general dwarf unwinders are looking very good in systemtap 1.3; porting s390 to them might be possible.
Comment 7 RHEL Product and Program Management 2010-07-12 15:54:50 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.