RFR: 8289688: jfr command hangs when it processes invalid file

[Yasumasa Suenaga]

On Mon, 11 Jul 2022 03:05:56 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> It looks like the real problem is how GraalVM Native Image writes recording data.

Agree.


> If the header is complete, is 68 bytes or more, the size of the field should be larger than 0. If the size filed is updated during a recording, it should use the proper protocol (modifying the file state in the header) to make sure the update is atomic.
> 
> The new check (c <= 0) is added where the value is read for logging, which is an "unreliable" read. The JVM might be modifying bytes in the header at the same time as it is being read by the parser, so it can be incorrect. Not sure we should add checks here. The magic and version are checked today, but they never change for a recording.

Did you say JVM would write recording file with random access?
Even if that is the case, it means recording file might be "unreliable" when it conflicts reading / writing, isn't it? I think jfr command should throw an error in that case.

> I would try to change this in GraalVM Native Image image instead.

I agree with you to fix GraalVM Native Image.
However, according to your comment, recording file might be invalid in corner case, so I think it is better to handle it.

In JMC, we can see error dialog in that case.
![jmc](https://user-images.githubusercontent.com/7421132/178502349-6fecadec-78f7-4406-aaef-e4015b9c40df.png)

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

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