All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: acme@redhat.com, peterz@infradead.org, jolsa@kernel.org,
	mingo@kernel.org, linux-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org, bp@suse.de,
	linux-arch@vger.kernel.org, Alexey.Brodkin@synopsys.com
Subject: Re: [PATCH 4/5] perf tools: [uclibc] don't rely on glibc malloc working for sz 0
Date: Thu, 8 Jan 2015 16:51:25 +0900	[thread overview]
Message-ID: <20150108075125.GF7268@sejong> (raw)
In-Reply-To: <1420552335-26886-5-git-send-email-vgupta@synopsys.com>

Hi Vineet,

On Tue, Jan 06, 2015 at 07:22:14PM +0530, Vineet Gupta wrote:
> When running perf on ARC (uClibc based userspace), ran into this issue
> ------------->8----------------
> 	[ARCLinux]$ ./perf record ls
> 	bin             etc             perf            sys
> 	debug           init            perf.data       tmp
> 	[ perf record: Woken up 1 times to write data ]
> 	[ perf record: Captured and wrote 0.001 MB perf.data (~24 samples) ]
> 
> 	[ARCLinux]$ ./perf report
> 	incompatible file format (rerun with -v to learn more)
> ------------->8----------------
> 
> The problem happens in the following call stack when zalloc is called
> with size zero
> 
> glibc default / uClibc with MALLOC_GLIBC_COMPAT are OK, but not if that
> config option is not enabled.
> 
>   cmd_report
>      perf_session__new
> 	perf_session__open
> 	    perf_session__read_header
> 		read_attr(fd, header, &f_attr)
> 		nr_ids = f_attr.ids.size / sizeof(u64); <-- 0
> 		perf_evsel__alloc_id(vsel, 1, nr_ids)
> 			zalloc(ncpus * nthreads * sizeof(u64)) <-- 0
> 
> header.c: read_attr()
> 
> (gdb) p *f_attr
> $17 = {
>   attr = {
>     type = 0,
>     size = 96,
>     config = 0,
>     {
>       sample_period = 4000,
>       sample_freq = 4000
>     },
> ...
>   ids = {
>     offset = 104,
>     size = 0      <------
>   }
> }

Hmm.. okay.  I think we don't need to allocate the id arrays when size
is 0.  So perf_event__process_attr() will have the same problem IMHO.
How about this?


diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1e90c8557ede..1d826d63bc20 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -797,6 +797,9 @@ int perf_evsel__enable(struct perf_evsel *evsel, int ncpus, int nthreads)
 
 int perf_evsel__alloc_id(struct perf_evsel *evsel, int ncpus, int nthreads)
 {
+	if (ncpus == 0 || nthreads == 0)
+		return 0;
+
 	if (evsel->system_wide)
 		nthreads = 1;
 

  reply	other threads:[~2015-01-08  7:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06 13:52 [PATCH 0/5] Perf fixes for ARC + uClibc Vineet Gupta
2015-01-06 13:52 ` Vineet Gupta
2015-01-06 13:52 ` [PATCH 1/5] perf tools: [uclibc] fix statfs.f_type data type mismatch build error Vineet Gupta
2015-01-06 13:52   ` Vineet Gupta
2015-01-06 13:52 ` [PATCH 2/5] perf tools: [uclibc] Elide strlcpy warning Vineet Gupta
2015-01-06 13:52   ` Vineet Gupta
2015-01-06 13:52 ` [PATCH 3/5] perf tools: [uclibc] Avoid build splat for syscall numbers Vineet Gupta
2015-01-06 13:52   ` Vineet Gupta
2015-01-06 13:52 ` [PATCH 4/5] perf tools: [uclibc] don't rely on glibc malloc working for sz 0 Vineet Gupta
2015-01-06 13:52   ` Vineet Gupta
2015-01-08  7:51   ` Namhyung Kim [this message]
2015-01-10 10:16     ` Vineet Gupta
2015-01-10 10:44       ` Namhyung Kim
2015-01-06 13:52 ` [PATCH 5/5] perf tools: [uclibc] provide stub for pthread_attr_setaffinity_np Vineet Gupta
2015-01-06 13:52   ` Vineet Gupta
2015-01-08  7:56   ` Namhyung Kim
2015-01-10 10:30     ` Vineet Gupta
2015-01-06 15:13 ` [PATCH 0/5] Perf fixes for ARC + uClibc Arnaldo Carvalho de Melo
2015-01-07  5:16   ` Vineet Gupta
2015-01-07  7:38   ` Vineet Gupta
2015-01-09 18:47     ` Alexey Brodkin

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=20150108075125.GF7268@sejong \
    --to=namhyung@kernel.org \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=acme@redhat.com \
    --cc=bp@suse.de \
    --cc=jolsa@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.