linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Metin Kaya <metin.kaya@arm.com>
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:17:51 -0400	[thread overview]
Message-ID: <20241018101751.76f6886f@gandalf.local.home> (raw)
In-Reply-To: <6c67124d-a806-42d6-a2c5-a74cccb4fce3@arm.com>

On Fri, 18 Oct 2024 10:13:11 +0100
Metin Kaya <metin.kaya@arm.com> wrote:

> 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.

Yeah, this is probably something different.

> 
> >   
> >> 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
>    ...

Hmm, looking at the code, I think it should be using trace_marker_raw and
not trace_marker. Although I don't believe that will fix this, it is still
something that needs to be changed.

-	path = tracefs_instance_get_file(instance, "trace_marker");
+	path = tracefs_instance_get_file(instance, "trace_marker_raw");

As trace_marker expects strings but trace_marker_raw takes binary data, and
we are writing binary data here.

Could you also add a "perror()" when it fails. The ret=-1 means the write
failed, so it would be good to know why it failed.

>    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

Can you tell me what is at line 2252 because I don't know what patches you
have applied, and 2252 in my code doesn't mean anything.

Thanks,

-- Steve

  reply	other threads:[~2024-10-18 14:17 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
2024-10-18 14:17       ` Steven Rostedt [this message]
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=20241018101751.76f6886f@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=metin.kaya@arm.com \
    /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).