public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug runtime/30408] New: Always fail to read userland memory (read faults) inside perf event probes with 6.2 kernels
@ 2023-04-30  6:28 agentzh at gmail dot com
  2023-05-02 22:31 ` [Bug runtime/30408] " agentzh at gmail dot com
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: agentzh at gmail dot com @ 2023-04-30  6:28 UTC (permalink / raw)
  To: systemtap

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

            Bug ID: 30408
           Summary: Always fail to read userland memory (read faults)
                    inside perf event probes with 6.2 kernels
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: agentzh at gmail dot com
  Target Milestone: ---

I've noted a regression of stap when using Fedora 36 x86_64's latest 6.2.12
kernel. It always fails to read userland memory inside a perf event probe
handler. It can be demonstrated by the following minimal example.

First prepare a small C program as the tracing target:

```
#include <stdio.h>

unsigned long a = 0;

void foo (void) {
    FILE *f = fopen("/dev/null", "w");
    fputs("hello world!\n", f);
    fclose(f);
}

int main (void) {
    while (1) {
        a++;
        for (int i = 0; i < 100; i++) {
            foo();
            foo();
        }
    }
    return 0;
}
```

Then we compile it with debug symbols:

```
gcc -g a.c
```

And we copy the resulting `./a.out` program file to `/tmp/`:

```
cp a.out /tmp/
```

Now we prepare a small stap script file named c.stp:

```
global fails = 0;

probe perf.type(1).config(0).sample(1000000) {
    if (execname() == "a.out") {
        ok = 1;
        val = 0;
        try {
            val = @var("a", "/tmp/a.out");
        } catch {
            ok = 0;
            fails++;
        }
        if (ok) {
            printf("a = %d\n", val);
            exit();
        }
    }
}

probe begin {
    warn("Start tracing...");
}

probe timer.s(2) {
    printf("failed %ld times\n", fails);
}
```

And we run it like this:

```
/opt/stap/bin/stap -c /tmp/a.out c.stp
WARNING: Start tracing...
failed 3927 times
failed 7854 times
failed 11769 times
failed 15741 times
failed 19705 times
failed 23671 times
failed 27668 times
failed 31639 times
failed 35613 times
failed 39563 times
failed 43491 times
failed 47463 times
failed 51465 times
...
```

No matter how long we wait, it always fails to read anything from `@var()`.

For comparison, I also ran this example on an older kernel (5.0.16) of an older
Fedora system and it works fine:

```
$ /opt/stap/bin/stap -c ./a.out c.stp
WARNING: Start tracing...
a = 150746
```

So it's definitely a behavior regression with the new kernel.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-05-16 19:51 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-30  6:28 [Bug runtime/30408] New: Always fail to read userland memory (read faults) inside perf event probes with 6.2 kernels agentzh at gmail dot com
2023-05-02 22:31 ` [Bug runtime/30408] " agentzh at gmail dot com
2023-05-02 22:32 ` [Bug runtime/30408] Always fail to read userland memory (read faults) inside perf event probes with 6.2/6.1 kernels agentzh at gmail dot com
2023-05-09 19:59 ` agentzh at gmail dot com
2023-05-09 20:04 ` agentzh at gmail dot com
2023-05-13  5:33 ` agentzh at gmail dot com
2023-05-13  6:28 ` agentzh at gmail dot com
2023-05-16 19:28 ` agentzh at gmail dot com
2023-05-16 19:51 ` agentzh at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).