linux-kernel - Re: [PATCH 1/2] perf data: Show error message when ctf setup failed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150410123743.GD31326@krava.brq.redhat.com>
Date:	Fri, 10 Apr 2015 14:37:43 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Alexandre Montplaisir <alexmonthy@...populi.im>
Cc:	He Kuang <hekuang@...wei.com>, bigeasy@...utronix.de,
	jolsa@...nel.org, acme@...nel.org, a.p.zijlstra@...llo.nl,
	mingo@...hat.com, wangnan0@...wei.com,
	linux-kernel@...r.kernel.org,
	Jérémie Galarneau 
	<jeremie.galarneau@...icios.com>
Subject: Re: [PATCH 1/2] perf data: Show error message when ctf setup failed

On Fri, Apr 10, 2015 at 02:05:45PM +0200, Jiri Olsa wrote:

SNIP

> > >>I tested by using babeltrace binary and it works.
> > >>
> > >>After receiving your reply, I test on the latest tracecompass. A
> > >>folder named 'ctf' is showed instead of the expected file
> > >>'ctf-data', this folder only contains the raw metadata and
> > >>perf-stream files but not analysed.
> > >CC-ing Alexandre from tracecompass devel ^^^
> > 
> > Hi,
> > 
> > I just came back from vacation, sorry for not replying earlier!
> > 
> > I managed to compile perf with CTF support, but by using Babeltrace's commit
> > 5584a48. It fails to compile against current master, because of private
> > headers getting exposed. I reported that to the BT maintainers.
> 
> there's fix in babeltrace tree already
> 
> > 
> > Then it seems there's another bug with Trace Compass's current master, trace
> > validation cannot fail, and any file will get imported with no errors. We
> > will look into this.
> > But the root of the problem was that the converted CTF trace was not being
> > recognized as valid. This is because some events define "stream_id = 0;",
> > and others don't specify a stream_id at all. It seems quite random, see the
> > full metadata here: http://pastebin.com/pACgV5JU
> > 
> > Is there a reason why some events specify a stream_id and some don't?
> 
> hum, that seems like a bug.. I'll check
>

ok, found the problem.. the "stream_id" event_class's attribute is created
only when the instance of the event (not event_class) is created

so you'll see the stream_id attribute only for events, that
we actually got data for.. the rest is without, because
their instance was never created

seems to me like libbabeltrace bug, unless the application should
take care about stream_id attribute.. but it's not the case for
the rest of the 'internal' attributes.. Jeremie?

anyway, I made a attached workaround and it all works nicely again,
tracecompass is happy and shows the data properly

I put all the pending ctf changes (plus the workaround) into:
  git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
  perf/ctf branch

jirka


---
diff --git a/tools/perf/util/data-convert-bt.c b/tools/perf/util/data-convert-bt.c
index 977cc3f98d8f..d7f03dcb1700 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -803,6 +803,7 @@ static int add_generic_types(struct ctf_writer *cw, struct perf_evsel *evsel,
 static int add_event(struct ctf_writer *cw, struct perf_evsel *evsel)
 {
 	struct bt_ctf_event_class *event_class;
+	struct bt_ctf_event *event;
 	struct evsel_priv *priv;
 	const char *name = perf_evsel__name(evsel);
 	int ret;
@@ -833,6 +834,14 @@ static int add_event(struct ctf_writer *cw, struct perf_evsel *evsel)
 	if (!priv)
 		goto err;
 
+	event = bt_ctf_event_create(event_class);
+	if (!event) {
+		pr_err("Failed to create an CTF event\n");
+		goto err;
+	}
+
+	bt_ctf_event_put(event);
+
 	priv->event_class = event_class;
 	evsel->priv       = priv;
 	return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/