[jdk18] RFR: 8279011: JFR: JfrChunkWriter incorrectly handles int64_t chunk size as size_t

[Markus Grönlund]

On Mon, 20 Dec 2021 16:34:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the investigation in the bug.
> 
> Spot the problem:
> 
> 
> int64_t JfrChunkWriter::write_chunk_header_checkpoint(bool flushpoint) {
>    ...
>    const size_t sz_written = size_written(); // <-- returns int64_t
>    write_be_at_offset(sz_written, chunk_size_offset); // <--- template instantiation with type=size_t
>    return sz_written;
>  }
> 
> 
> This would have been nearly fine -- small `size_t` -> `int64_t` conversion is okay value-wise. But `write_be_at_offset` calculates the position for the writeout using `sizeof(T)`, which silently borks the whole thing on at least 32-bit platforms, where `sizeof(size_t)` != `sizeof(int64_t)`. 
> 
> Additional testing:
>  - [x] Linux x86_64 `jdk_jfr` (no regressions)
>  - [x] Linux x86_32 `jdk_jfr` (many failing tests now pass)

Nice find.

But surprised there is not a compile error here (both incompatible type size and sign), if sizeof(size_t) == 4 and sizeof(int64_t) == 8:

const size_t sz_written = size_written(); // <-- returns int64_t

So the value is written as a 4-byte quantity only, since it is dimensioned using sizeof(size_t), and therefore does not fill the full 8- bytes slot associated with the 'chunksize' header field. And uninitialized memory in the high 4-bytes leads to this high value?

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

PR: https://git.openjdk.java.net/jdk18/pull/50