lkml.org 
[lkml]   [2013]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf: detect loops processing events
On 5/9/13 7:10 PM, Namhyung Kim wrote:
>
> I think we should not truncate file_size for this case. It was
> decreased to data_offset + data_size in order not to read unrelated
> metadata (additional header feature info). But in this case, since
> data_size is 0 it'd have same value as data_offset, and in turn
> mmap_size truncated to data_offset too. So fetch_mmaped_event() always
> return NULL as head + sizeof(event->header) exceeds mmap_size.
>
> If we keep original file_size, perf can report existing samples but no
> metadata. So does the patch below make sense?
>
>
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index cf1fe01b7e89..cf4e574c7b7f 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1196,7 +1196,7 @@ int __perf_session__process_events(struct perf_session *session,
> file_offset = page_offset;
> head = data_offset - page_offset;
>
> - if (data_offset + data_size < file_size)
> + if (data_size && (data_offset + data_size < file_size))
> file_size = data_offset + data_size;
>
> progress_next = file_size / 16;

Nice. That does handle the case of the perf.data file not getting closed
properly. With this, my patch should not return -1 just print the error
message to the user which would explain why the feature data is not printed.

David



\
 
 \ /
  Last update: 2013-05-10 04:21    [W:0.227 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site