On Fri, Aug 02, 2019 at 09:38:49AM -0700, Stephane Eranian wrote:
> Hi,
>
> When trying the following command line with perf from tip,git, I got:
>
> $ perf record --group -c 10 -e '{branch-misses,branches}' -a -o -
> sleep 1| perf report --no-group -F sample,cpu,period -i -
> # To display
Hi,
When trying the following command line with perf from tip,git, I got:
$ perf record --group -c 10 -e '{branch-misses,branches}' -a -o -
sleep 1| perf report --no-group -F sample,cpu,period -i -
# To display the perf.data header info, please use
--header/--header-only options.
#
Em Thu, Jul 25, 2019 at 03:04:32PM -0400, Vince Weaver escreveu:
>
> probably all perf_header_strings are affected by this. The fuzzer just
> tripped up cmdline now, which needs this fix.
I think we have to catch this earlier, i.e. when processing each
feature, lemme check...
- Arnaldo
>
Em Thu, Jul 25, 2019 at 02:27:14PM -0400, Vince Weaver escreveu:
> Hello,
>
> the perf_data_fuzzer found an issue when strings have size 0.
> malloc() in do_read_string() is happy to allocate a string of
> size 0 but when code (in this case the pmu parser) tries to work with
> those it will
probably all perf_header_strings are affected by this. The fuzzer just
tripped up cmdline now, which needs this fix.
Signed-off-by: Vince Weaver
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index c24db7f4909c..631aa1911f3a 100644
--- a/tools/perf/util/header.c
+++
Hello,
the perf_data_fuzzer found an issue when strings have size 0.
malloc() in do_read_string() is happy to allocate a string of
size 0 but when code (in this case the pmu parser) tries to work with
those it will segfault.
Signed-off-by: Vince Weaver
diff --git a/tools/perf/util/header.c
Em Wed, Oct 10, 2018 at 12:20:04AM +0200, Jiri Olsa escreveu:
> On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
> > I can try building perf from the latest sources. I've attached the
> > perf.data and perf.data.tar.bz2 from the test program I sent earlier.
>
> cool, reproduced..
Em Wed, Oct 10, 2018 at 12:20:04AM +0200, Jiri Olsa escreveu:
> On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
> > I can try building perf from the latest sources. I've attached the
> > perf.data and perf.data.tar.bz2 from the test program I sent earlier.
>
> cool, reproduced..
On Wed, Oct 10, 2018 at 11:13:47AM +0530, Sandipan Das wrote:
> Hi Jiri,
>
> Yes, this happens when entry->map is NULL. While your fix seems correct, the
> following commit from Milian Wolff had already addressed this. I think this
> was pulled in with one of Arnaldo's recent perf/urgent updates.
On Wed, Oct 10, 2018 at 11:13:47AM +0530, Sandipan Das wrote:
> Hi Jiri,
>
> Yes, this happens when entry->map is NULL. While your fix seems correct, the
> following commit from Milian Wolff had already addressed this. I think this
> was pulled in with one of Arnaldo's recent perf/urgent updates.
* Sandipan Das wrote:
> Hi Jiri,
>
> Yes, this happens when entry->map is NULL. While your fix seems correct, the
> following commit from Milian Wolff had already addressed this. I think this
> was pulled in with one of Arnaldo's recent perf/urgent updates.
>
> ff4ce2885af8 ("perf report:
* Sandipan Das wrote:
> Hi Jiri,
>
> Yes, this happens when entry->map is NULL. While your fix seems correct, the
> following commit from Milian Wolff had already addressed this. I think this
> was pulled in with one of Arnaldo's recent perf/urgent updates.
>
> ff4ce2885af8 ("perf report:
Hi Jiri,
Yes, this happens when entry->map is NULL. While your fix seems correct, the
following commit from Milian Wolff had already addressed this. I think this
was pulled in with one of Arnaldo's recent perf/urgent updates.
ff4ce2885af8 ("perf report: Don't try to map ip to invalid map")
Hi Jiri,
Yes, this happens when entry->map is NULL. While your fix seems correct, the
following commit from Milian Wolff had already addressed this. I think this
was pulled in with one of Arnaldo's recent perf/urgent updates.
ff4ce2885af8 ("perf report: Don't try to map ip to invalid map")
On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
> I can try building perf from the latest sources. I've attached the
> perf.data and perf.data.tar.bz2 from the test program I sent earlier.
cool, reproduced.. it seems to get introduced by:
2a9d5050dc84 perf script: Show correct
On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
> I can try building perf from the latest sources. I've attached the
> perf.data and perf.data.tar.bz2 from the test program I sent earlier.
cool, reproduced.. it seems to get introduced by:
2a9d5050dc84 perf script: Show correct
Ok, I tried it with the version compiled from the latest sources and I
don't get the segfault, so it must be an issue with the version
distributed with Fedora 27.
Tony
On Tue, Oct 9, 2018 at 4:47 PM Anthony LaTorre wrote:
>
> I can try building perf from the latest sources. I've attached the
>
Ok, I tried it with the version compiled from the latest sources and I
don't get the segfault, so it must be an issue with the version
distributed with Fedora 27.
Tony
On Tue, Oct 9, 2018 at 4:47 PM Anthony LaTorre wrote:
>
> I can try building perf from the latest sources. I've attached the
>
On Tue, Oct 09, 2018 at 03:18:12PM -0500, Anthony LaTorre wrote:
> Ok, I can reliably reproduce it by profiling the following program:
>
> #include
>
> int main(int argc, char **argv)
> {
> int i;
> double sum;
>
> while (1) {
> sum += exp(++i);
> }
>
> return 0;
>
On Tue, Oct 09, 2018 at 03:18:12PM -0500, Anthony LaTorre wrote:
> Ok, I can reliably reproduce it by profiling the following program:
>
> #include
>
> int main(int argc, char **argv)
> {
> int i;
> double sum;
>
> while (1) {
> sum += exp(++i);
> }
>
> return 0;
>
On Tue, Oct 09, 2018 at 01:54:48PM -0500, Anthony LaTorre wrote:
> Can you reproduce the segfault from the perf.data file I provided?
nope, but if it's dwarf callchain related I'd need perf archive
output to reproduce.. please run:
---
$ perf record ...
$ perf archive
Now please run:
$
On Tue, Oct 09, 2018 at 01:54:48PM -0500, Anthony LaTorre wrote:
> Can you reproduce the segfault from the perf.data file I provided?
nope, but if it's dwarf callchain related I'd need perf archive
output to reproduce.. please run:
---
$ perf record ...
$ perf archive
Now please run:
$
Ok, I can reliably reproduce it by profiling the following program:
#include
int main(int argc, char **argv)
{
int i;
double sum;
while (1) {
sum += exp(++i);
}
return 0;
}
compiled with:
$ cc -o test test.c -lm
with the following command:
$ perf record -F 99
Ok, I can reliably reproduce it by profiling the following program:
#include
int main(int argc, char **argv)
{
int i;
double sum;
while (1) {
sum += exp(++i);
}
return 0;
}
compiled with:
$ cc -o test test.c -lm
with the following command:
$ perf record -F 99
Can you reproduce the segfault from the perf.data file I provided?
Tony
On Tue, Oct 9, 2018 at 11:47 AM Jiri Olsa wrote:
>
> On Tue, Oct 09, 2018 at 11:27:04AM -0500, Anthony LaTorre wrote:
> > Hi,
> >
> > I'm currently running Linux kernel 4.18.10-100.fc27.x86_64 and have a
> > problem
Can you reproduce the segfault from the perf.data file I provided?
Tony
On Tue, Oct 9, 2018 at 11:47 AM Jiri Olsa wrote:
>
> On Tue, Oct 09, 2018 at 11:27:04AM -0500, Anthony LaTorre wrote:
> > Hi,
> >
> > I'm currently running Linux kernel 4.18.10-100.fc27.x86_64 and have a
> > problem
On Tue, Oct 09, 2018 at 11:27:04AM -0500, Anthony LaTorre wrote:
> Hi,
>
> I'm currently running Linux kernel 4.18.10-100.fc27.x86_64 and have a
> problem profiling a program that used to work. Currently when I
> profile the program with the following command:
>
> $ perf record -F 99 -p PID
On Tue, Oct 09, 2018 at 11:27:04AM -0500, Anthony LaTorre wrote:
> Hi,
>
> I'm currently running Linux kernel 4.18.10-100.fc27.x86_64 and have a
> problem profiling a program that used to work. Currently when I
> profile the program with the following command:
>
> $ perf record -F 99 -p PID
Hi folks,
I hit a segfault when try to analysis a perf.data generated in an aarch 64
board.
I tried execute perf report on x86 and arm64, both of them hit similar segfault:
$ perf report -i ./buggy/perf.data --objdump=/path/to/aarch64-oe-linux-objdump
--kallsyms /path/to/kallsyms
perf:
Hi folks,
I hit a segfault when try to analysis a perf.data generated in an aarch 64
board.
I tried execute perf report on x86 and arm64, both of them hit similar segfault:
$ perf report -i ./buggy/perf.data --objdump=/path/to/aarch64-oe-linux-objdump
--kallsyms /path/to/kallsyms
perf:
30 matches
Mail list logo
