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