Re: combined usage of `--aio -z` corrupts perf.data files - fallout from COMPRESSED2?

[Milian Wolff <milian.wolff@kdab.com>]

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