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

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

[Milian Wolff]

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.

Cheers
-- 
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - Trusted Software Excellence

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

[Milian Wolff]

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