linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Metin Kaya <metin.kaya@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH] libtracefs: Destroy synthetic and eprobes before other events
Date: Fri, 18 Oct 2024 10:13:11 +0100	[thread overview]
Message-ID: <6c67124d-a806-42d6-a2c5-a74cccb4fce3@arm.com> (raw)
In-Reply-To: <20241017160108.4f99c917@gandalf.local.home>

On 17/10/2024 9:01 pm, Steven Rostedt wrote:
> On Thu, 17 Oct 2024 09:38:35 +0100
> Metin Kaya <metin.kaya@arm.com> wrote:
> 
>> I see one more failure in this section of unit tests:
>>
>>     Test: tracefs_iterate_snapshot_events API ...FAILED
>>       1. tracefs-utest.c:235  - ret == sizeof(struct test_sample)
>>       2. tracefs-utest.c:235  - ret == sizeof(struct test_sample)
>>       3. tracefs-utest.c:235  - ret == sizeof(struct test_sample)
>>
> 
> Does this occur without this patch? IOW, is this caused by this patch?

I thought there were 2 "tracefs-utest.c:235  - ret == sizeof(struct 
test_sample)" failures before this patch and this patch increased the 
number of failures by 1. However, this does not seem to be 100% correct. 
I sometimes see only 1 failure, but then there are 2-3 of them.

I do trace-cmd reset && unmount before running the unit tests.

> 
>> I did run trace-cmd reset and unmounted my tracefs before running the
>> unit tests.
>> Please feel free to ignore if something is weirdly wrong in my setup.
>>
>> Other than that -kind of existing- failure, the patch looks good to me
>> (e.g., trace-cmd unit tests are working fine).
> 
> 
> Can you add a printf("ret = %d\n", ret) to find out what "ret" is?

Here is the output with printf's:

   ...
   Test: tracefs_iterate_snapshot_events API ...
line=237 i=87 path=n~_ cpu=55 value=2046397138 ret=-1
FAILED
     1. tracefs-utest.c:240  - ret == sizeof(struct test_sample)
   Test: tracefs_iterate_raw_events API ...
line=237 i=1444 path=~_ cpu=50 value=1150454427 ret=-1
FAILED
     1. tracefs-utest.c:240  - ret == sizeof(struct test_sample)
   Test: Follow events ...passed
   ...
   Test: uprobes ...
line=2229 ename=utest_u 
address=/libtracefs/utest/trace-utest:0x00000000000003e8 event=utest_u 
system=utest format=arg1=$stack2 prefix=p type=0x000004 ret=-1

line=2229 ename=utest_r 
address=/libtracefs/utest/trace-utest:0x00000000000003e8 event=utest_r 
system=utest format=arg1=$retval prefix=r type=0x000008 ret=-1
FAILED
     1. tracefs-utest.c:2232  - ret == 0
     2. tracefs-utest.c:2232  - ret == 0


And this is the output with your "libtracefs utest: Fixes and new tests" 
patch series [1]:

   Test: tracefs_iterate_raw_events API ...
line=237 i=2532 path=Db cpu=0 value=1144606227 ret=-1

line=237 i=1285 path=ו3b cpu=6 value=1157898007 ret=-1
FAILED
     1. tracefs-utest.c:240  - ret == sizeof(struct test_sample)
     2. tracefs-utest.c:240  - ret == sizeof(struct test_sample)
   Test: Follow events ...passed
   Test: Follow events clear ...passed
   Test: tracefs_tracers API ...passed
   Test: tracefs_local events API ...passed
   Test: tracefs_instances_walk API ...passed
   Test: tracefs_get_clock API ...passed
   Test: tracing on / off ...passed
   Test: tracing options ...passed
   Test: custom system directory ...passed
   Test: ftrace marker ...passed
   Test: kprobes ...passed
   Test: synthetic events ...passed
   Test: eprobes ...passed
   Test: uprobes ...
line=2249 ename=utest_u 
address=/ssd/tracecmd-work/libtracefs/utest/trace-utest:0x00000000000003e8 
event=utest_u system=utest format=arg1=$stack2 prefix=p type=0x000004 ret=-1

line=2249 ename=utest_r 
address=/ssd/tracecmd-work/libtracefs/utest/trace-utest:0x00000000000003e8 
event=utest_r system=utest format=arg1=$retval prefix=r type=0x000008 ret=-1
FAILED
     1. tracefs-utest.c:2252  - ret == 0
     2. tracefs-utest.c:2252  - ret == 0
   Test: multi probe test ...
line=2249 ename=utest_u 
address=/ssd/tracecmd-work/libtracefs/utest/trace-utest:0x00000000000003e8 
event=utest_u system=utest format=arg1=$stack2 prefix=p type=0x000004 ret=-1

line=2249 ename=utest_r 
address=/ssd/tracecmd-work/libtracefs/utest/trace-utest:0x00000000000003e8 
event=utest_r system=utest format=arg1=$retval prefix=r type=0x000008 ret=-1
FAILED
     1. tracefs-utest.c:2252  - ret == 0
     2. tracefs-utest.c:2252  - ret == 0

Thanks,

[1] 
https://lore.kernel.org/linux-trace-devel/20241017200609.932728-1-rostedt@goodmis.org 


  reply	other threads:[~2024-10-18  9:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-16 16:35 [PATCH] libtracefs: Destroy synthetic and eprobes before other events Steven Rostedt
2024-10-17  8:38 ` Metin Kaya
2024-10-17 20:01   ` Steven Rostedt
2024-10-18  9:13     ` Metin Kaya [this message]
2024-10-18 14:17       ` Steven Rostedt
2024-10-18 14:51         ` Metin Kaya
2024-11-20  3:57           ` Steven Rostedt
2024-11-20  7:42             ` Metin Kaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c67124d-a806-42d6-a2c5-a74cccb4fce3@arm.com \
    --to=metin.kaya@arm.com \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).