Control: tag -1 - unreproducible moreinfo Control: tag -1 upstream fixed-upstream patch
On Mon, 2012-12-31 at 05:28 +1100, Michael van der Kolff wrote: > On Mon, Dec 31, 2012 at 2:11 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > > > > Control: tag -1 unreproducible > > > > On Sun, 2012-12-30 at 08:56 +1100, Michael van der Kolff wrote: > > > Package: linux-tools-3.2 > > > Version: 3.2.17-1 > > > Severity: normal > > > > > > Dear Maintainer, > > > When issuing "perf record -p <annoying_process_id> -g", I got "Fatal: > > > failed to > > > mmap with 22 (Invalid argument)". This is remedied by setting > > > /proc/sys/kernel/perf_event_paranoid to -1 (I tested it with 0, and it > > > still > > > occurred). > > > > > > perf record should state what sys.kernel.perf_event_paranoid should be > > > set to > > > in response to failure, instead of giving me such a useless error message. > > > > I can't reproduce this: > > > > $ perf record -p 20140 -g # 20140 is my own process > > ^C[ perf record: Woken up 1 times to write data ] > > [ perf record: Captured and wrote 0.015 MB perf.data (~634 samples) ] > > $ perf record -p 1 -g > > Error: > > Permission error - are you root? > > Consider tweaking /proc/sys/kernel/perf_event_paranoid: > > > It was the fact that this popped when I was trying to look at a > process that wasn't my own that got me thinking :) > > > Is the target process running under the same uid as perf? Can you > > provide an strace log for this? > > > Yep: > mvanderkolff@mvdk-pers-lap:~$ ps ux | grep 5309 > 1000 5309 16.3 11.6 972360 695208 ? SNl 05:13 1:34 > /usr/lib/tracker/tracker-miner-fs > 1000 6399 0.0 0.0 7832 876 pts/0 S+ 05:23 0:00 grep 5309 > mvanderkolff@mvdk-pers-lap:~$ (strace perf record -p 5309) > strace.log 2>&1 > mvanderkolff@mvdk-pers-lap:~$ id > uid=1000(mvanderkolff) gid=1000(mvanderkolff) > groups=1000(mvanderkolff),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),105(scanner),110(bluetooth),112(netdev) > mvanderkolff@mvdk-pers-lap:~$ tail strace.log > mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = -1 EPERM > (Operation not permitted) > munmap(0x7fe4ae2d8000, 528384) = 0 > munmap(0x7fe4ae257000, 528384) = 0 > munmap(0x7fe4ae1d6000, 528384) = 0 > munmap(0x7fe4aaf58000, 528384) = 0 > munmap(0xffffffffffffffff, 528384) = -1 EINVAL (Invalid argument) > write(2, " Fatal: failed to mmap with 22 "..., 52 Fatal: failed to > mmap with 22 (Invalid argument) > > ) = 52 > exit_group(128) = ? OK, I get it. It's doing some cleanup after the first error, which also fails and changes the error code. And then it reports the second error. This was fixed upstream (sort of) in v3.3, and I might be able to include that in an update. I can't promise it will be considered important enough to fix at this point in the release, though. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
