* Re: combined usage of `--aio -z` corrupts perf.data files - fallout from COMPRESSED2?
2025-09-10 8:51 combined usage of `--aio -z` corrupts perf.data files - fallout from COMPRESSED2? Milian Wolff
@ 2025-09-12 12:31 ` Milian Wolff
0 siblings, 0 replies; 2+ messages in thread
From: Milian Wolff @ 2025-09-12 12:31 UTC (permalink / raw)
To: linux-perf-users; +Cc: Chun-Tse Shao, acme
On Mittwoch, 10. September 2025 10:51:31 Mitteleuropäische Sommerzeit Milian
Wolff wrote:
> Hey all,
>
> for some context, see https://github.com/KDAB/hotspot/issues/
> 736#issuecomment-3273734660
>
> The gist is the following:
>
> ```
> $ perf record --call-graph dwarf -z --aio -- ls
> ...
> [ perf record: Captured and wrote 0.005 MB perf.data, compressed (original
> 0.101 MB, ratio is 28.747) ]
> $ perf script
> Couldn't decompress data
> 0x598 [0xe53]: failed to process type: 83 [Operation not permitted]
> ```
>
> If you remove the explicit `--aio` while keeping compression via `-z`
> enabled, then the result file can be parsed. Enabling `--aio` but disabling
> `-z` also works as expected.
>
> My understanding so far was that `-z` implies `--aio`, and that there should
> be zero semantic difference between `-z` and `-z --aio`. But apparently
> this was a misunderstanding on my end.
>
> I suspect that the above issue is related to the recent addition of the
> COMPRESSED2 record type, since commands combining both of these flags used
> to work fine until very recently.
Hello all,
there are apparently even issues with just `-z` and no `--aio`. Instead, I'm
now setting a larger buffer size:
```
$ perf record -m 16M -z --call-graph dwarf -e cycles ./test
failed to write perf data, error: Bad address
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.138 MB perf.data, compressed (original
10.517 MB, ratio is 83.180) ]
$ perf script
failed to decompress (B): 113080 -> 16781312, dst_size 16781312 : Data
corruption detected
Couldn't decompress data
0x2df0 [0xb9c8]: failed to process type: 83 [Operation not permitted]
```
The code for the `test` binary used above is available here: https://
invent.kde.org/-/snippets/3549
If I use `-m 8M` instead of `-m 16M` the error above disappears. Is there
possibly an overflow somewhere, considering that the compressed record size
used to be only 16bit, but now is uint64 for COMPRESSED2? See:
> PERF_RECORD_COMPRESSED = 81, /* deprecated */
>
> The header is followed by compressed data frame that can be decompressed
> into array of perf trace records. The size of the entire compressed event
> record including the header is limited by the max value of header.size.
From `perf_event.h`:
> u16 header_size;
But then we now have:
> PERF_RECORD_COMPRESSED2 = 83,
>
> 8-byte aligned version of `PERF_RECORD_COMPRESSED`. `header.size` indicates
> the
> total record size, including padding for 8-byte alignment, and `data_size`
> specifies the actual size of the compressed data.
>
> struct perf_record_compressed2 {
> struct perf_event_header header;
> __u64 data_size;
> char data[];
> };
Just a hunch, I'm not really sure this is the reason - but it does look funky
to me.
Note: this all happens on a linux kernel 6.16.5-arch1-1 with perf in the same
version 6.16-1.
--
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - Trusted Software Excellence
^ permalink raw reply [flat|nested] 2+ messages in thread