RFR: 8297402: jfr tool processes large padded integers incorrectly
Ekaterina Vergizova
evergizova at openjdk.org
Tue Nov 22 18:35:25 UTC 2022
On Tue, 22 Nov 2022 15:06:20 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.
-------------
PR: https://git.openjdk.org/jdk/pull/11289
More information about the hotspot-jfr-dev
mailing list