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
next prev parent 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).