1. Please describe the problem: : Running `perf` inside the Flatpak sandbox causes it to crash. IDK whether to report this to `perf` or `flatpak`, so I chose `perf`, since that appeared to be `gnome-abrt`'s preference. https://bugzilla.redhat.com/show_bug.cgi?id=2366461#c21 is an example of that preference. 2. What is the Version-Release number of the kernel: : `kernel-6.14.6-300.fc42.x86_64`, but I imagine that `perf-6.14.6-300.fc42.x86_64` is of more use to you. 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : : `kernel-6.14.6-300.fc42.x86_64`, but this is probably inapplicable. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: : With the undermentioned as a reference (from `flatpak info`): > ~~~YAML > ID: com.github.Murmele.Gittyup > Ref: app/com.github.Murmele.Gittyup/x86_64/stable > Arch: x86_64 > Branch: stable > Version: v1.4.0 > License: MIT > Origin: flathub > Collection: org.flathub.Stable > Installation: system > Installed: 72.4 MB > Runtime: org.kde.Platform/x86_64/5.15-23.08 > Sdk: org.kde.Sdk/x86_64/5.15-23.08 > > Commit: adfe463ee26a63bdaaa0af13f71e26bf9a925d37f43b4527c7b14625ab5a08a7 > Parent: 7e1c9370a1a462478b7fac34aac11882cb62768886aa23fe4fd36fb23c17e19b > Subject: update to release 1.4.0 (#44) (21f22a60) > Date: 2024-05-15 22:15:19 +0000 > ~~~ Install and invoke the debug version, as the undermentioned demonstrates: ~~~sh #!/usr/bin/env sh flatpak install --include-sdk --include-debug com.github.Murmele.Gittyup -y && \ flatpak run --command=sh --devel com.github.Murmele.Gittyup ~~~ Inside, run `perf record --call-graph dwarf gittyup`. For me, this caused: > ~~~log > Failed to read max cpus, using default of 4096 > libperf: Miscounted nr_mmaps 0 vs 1 > WARNING: No sample_id_all support, falling back to unordered processing > perf: Segmentation fault > Obtained 15 stack frames. > perf(dump_stack+0x37) [0x5614639dbcc7] > perf(sighandler_dump_stack+0x2f) [0x5614639dbd6f] > /usr/lib/x86_64-linux-gnu/libc.so.6(+0x3ee80) [0x7f1946251e80] > perf(perf_cpu_map__max+0x4) [0x5614638bec14] > perf(+0x271f74) [0x561463a34f74] > perf(perf_event__synthesize_cpu_map+0x56) [0x561463a37dd6] > perf(+0x8a28b) [0x56146384d28b] > perf(+0x8dd7f) [0x561463850d7f] > perf(cmd_record+0xe37) [0x561463854017] > perf(+0xf8cf2) [0x5614638bbcf2] > perf(+0xf8ffb) [0x5614638bbffb] > perf(main+0x2e7) [0x56146383adb7] > /usr/lib/x86_64-linux-gnu/libc.so.6(+0x2808a) [0x7f194623b08a] > /usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7f194623b14b] > perf(_start+0x25) [0x56146383b405] > Segmentation fault (core dumped) > ~~~ Afterward, I invoked `gdb --args perf record '--call-graph' dwarf gittyup` (with DebugInfoD enabled) to capture a trace. It did indeed, for I saw: > ~~~CPP > Failed to read max cpus, using default of 4096 > [Detaching after fork from child process 18] > libperf: Miscounted nr_mmaps 0 vs 1 > WARNING: No sample_id_all support, falling back to unordered processing > > Program received signal SIGSEGV, Segmentation fault. > perf_cpu_map__max (map=0x0) at cpumap.c:362 > 362 return __perf_cpu_map__nr(map) > 0 > (gdb) bt full > #0 perf_cpu_map__max (map=0x0) at cpumap.c:362 > result = {cpu = -1} > #1 0x00005555557c5f74 in cpu_map_data__alloc (syn_data=syn_data@entry=0x7fffffff7790, header_size=header_size@entry=8) at util/synthetic-events.c:1289 > size_cpus = <optimized out> > size_mask = <optimized out> > #2 0x00005555557c8dd6 in cpu_map_event__new (map=<optimized out>) at util/synthetic-events.c:1337 > syn_data = {map = 0x0, nr = 1, min_cpu = -1, max_cpu = 0, has_any_cpu = 1, type = 0, size = 0, data = 0x0} > event = <optimized out> > syn_data = <optimized out> > event = <error reading variable event (Cannot access memory at address 0x0)> > #3 perf_event__synthesize_cpu_map (tool=tool@entry=0x555555f10d80 <record>, map=<optimized out>, process=process@entry=0x5555555e0270 <process_synthesized_event>, machine=machine@entry=0x0) at util/synthetic-events.c:1357 > event = <optimized out> > err = <optimized out> > #4 0x00005555555de28b in record__synthesize (tail=tail@entry=false, rec=0x555555f10d80 <record>) at builtin-record.c:2099 > session = 0x555555f4a830 > machine = 0x555555f4aa48 > data = 0x555555f10fc8 <record+584> > opts = 0x555555f10ec0 <record+320> > tool = 0x555555f10d80 <record> > err = 0 > f = 0x5555555e0270 <process_synthesized_event> > out = <optimized out> > #5 0x00005555555e1d7f in __cmd_record (argc=argc@entry=1, argv=argv@entry=0x7fffffffd410, rec=0x555555f10d80 <record>) at builtin-record.c:2539 > err = <optimized out> > status = 0 > forks = true > tool = 0x555555f10d80 <record> > opts = 0x555555f10ec0 <record+320> > data = 0x555555f10fc8 <record+584> > session = 0x555555f4a830 > disabled = false > --Type <RET> for more, q to quit, c to continue without paging--c > draining = false > fd = 3 > ratio = 0 > cmd = EVLIST_CTL_CMD_UNSUPPORTED > #6 0x00005555555e5017 in cmd_record (argc=<optimized out>, argv=<optimized out>) at builtin-record.c:4260 > err = <optimized out> > rec = 0x555555f10d80 <record> > errbuf = '\000' <repeats 2280 times>... > #7 0x000055555564ccf2 in run_builtin (p=p@entry=0x555555f1c720 <commands+288>, argc=argc@entry=4, argv=argv@entry=0x7fffffffd410) at perf.c:351 > status = <optimized out> > st = {st_dev = 93825002648512, st_ino = 93825002652944, st_nlink = 140737488343280, st_mode = 898607616, st_uid = 4080433966, st_gid = 32, __pad0 = 0, st_rdev = 140737488344080, st_size = 140737488350882, st_blksize = -921413635353368064, > st_blocks = 140737488343472, st_atim = {tv_sec = 140737335991347, tv_nsec = 140737488350882}, st_mtim = {tv_sec = 2, tv_nsec = 140737488343472}, st_ctim = {tv_sec = 93825002655776, tv_nsec = 93825002655808}, __glibc_reserved = { > 140737337308368, 140737488343344, 140737336478438}} > sbuf = "Ж\343\366\377\177\000\000\020Q\364UUU\000\0000\321\377\377\000\000\000\000(P\364UUU\000\000\000\000\000\000\000\000\000\000\3204\377\366\377\177\000\000Ж\343\366\377\177\000\000\235\356\377\377\377\177\000\000\310N\364UUU\000\000\000\252\2175.{6\363\340\321\377\377\377\177\000\000\207_oUUU\000\000\000\000\000\b\000\000\000\000\300P\364UUU\000\000\260\321\377\377\377\177\000\0003\331\377\377\377\177\000" > out = <optimized out> > #8 0x000055555564cffb in handle_internal_command (argc=argc@entry=4, argv=argv@entry=0x7fffffffd410) at perf.c:404 > p = 0x555555f1c720 <commands+288> > cmd = 0x7fffffffd933 "record" > i = 12 > #9 0x00005555555cbdb7 in run_argv (argv=<synthetic pointer>, argcp=<synthetic pointer>) at perf.c:448 > No locals. > #10 main (argc=<optimized out>, argv=0x7fffffffd410) at perf.c:556 > err = <optimized out> > done_help = 0 > cmd = 0x7fffffffd933 "record" > sbuf = "\000\000\000\000\000\000\000\000\200\322\377\377\377\177\000\000\000\322\377\377\377\177\000\000\000\000\000\000\000\000\000\000\3003\364UUU\000\000p\322\377\377\377\177\000\000\3003\364UUU\000\000\240\357\362UUU", '\000' <repeats 26 times>, "\002\000\000\000\000\000\000\000\002\000\000\000\002\000\000\000\240G\364UUU\000\000\343\006\205UUU\000\000\343\006\205UUU\000" > ~~~ 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run `sudo dnf install fedora-repos-rawhide` followed by `sudo dnf update --enablerepo=rawhide kernel`: : I am unwilling to ascertain this. 6. Are you running any modules that not shipped with directly Fedora's kernel?: : I don't know, for I don't know how to ascertain this. I doubt it, though: I've WayDroid, but not VirtualBox. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with `journalctl --no-hostname -k > dmesg.txt`. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. : I'll provide it, but I doubt that it'll be useful. 8. Reproducibility: : Always.
Created attachment 2091632 [details] Requested DMesg Log
This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
In retrospect, because I was likely attempting to diagnose https://github.com/Murmele/Gittyup/issues/523#issuecomment-2909164635, this is, probably, an example of what https://bugzilla.redhat.com/show_bug.cgi?id=2374963#c17 describes.