RFR: 8297402: jfr tool processes large padded integers incorrectly

[Markus Grönlund]

On Tue, 22 Nov 2022 18:31:34 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

>> Could I have a review of a PR that fixes jfr tool reading of large padded integers.
>> 
>> Some integer values are written to jfr recordings using write_padded_at_offset<u4>() method. Their size in recording is always 4 bytes.
>> jfr tool reads all integer values by readInt() method, which doesn't take size into account.
>> For padded values greater than (1 << 28), jfr tool tries to read 5 bytes from recording and fails.
>> 
>> I suggest to fix reading of padded integers in jfr tool.
>> If a value is written by write_padded_at_offset<u4>() then it should be read by readPaddedInt() method which doesn't read more than 4 bytes.
>> (It can be less then 4 bytes due to JDK-8246260)
>> 
>> Tested with jdk/jfr and tier1.
>> jfr recording generated by TestHugeStackTracePool.java with jdk11 (attached to JDK-8297402) is successfully processed by jfr tool after the fix.
>
> Currently, the JVM does not check 2 ^ 28 limit in most cases when writing padded integers.
> For example, it doesn't validate or reject values for a large pool of stacktraces.
> 
> If such values are actually invalid, then I'll try to prepare a fix that splits the data into two events, if possible.

Hi @kvergizova, thanks for noticing this.

I ran into this situation a couple of months back and have an idea and suggestion to handle this situation. If you don't feel like digging too deep, I can either help you or take over this entirely.

Best regards
Markus

-------------

PR: https://git.openjdk.org/jdk/pull/11289