RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing
Axel Boldt-Christmas
aboldtch at openjdk.org
Wed Nov 9 08:26:08 UTC 2022
On Wed, 9 Nov 2022 07:23:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> How would this be different from what we are doing now?
I meant with regards to one specific reentrant step. Such that it could break out of the iteration early after X crashes, separate from any VMError::report limit.
> I agree, but my conclusion differs from yours: if a STEP does X, and X crashes repeatedly out, it makes sense at some point to stop doing X, since the probability that it will crash again is quite high. It is better to stop and proceed with the next STEPs, since their output may be more valuable than just another failed printout in the crashing STEP.
If every print crashes then something seems very wrong, I was more thinking that we get a few crashes in a specific subsystem, where getting a few repeated crashes on some specific address ranges help narrow down the problem. One crash might be unrelated, but two or three in a specific subsystem shows a trend and helps narrow down the root cause.
> I agree with @dean-long, it would be good to know what is going wrong first. And harden the printing code with os::is_readable_pointer. Because SafeFetch, in contrast to this STEP mechanism, does not build up stack. Or, if applying SafeFetch is no reasonable option, retry the whole STEP with risky options disabled, as I did here: #10179.
I agree, the norm should be that print location does not crash. As I mentioned in my reply above I have only seen it when I introduce it myself.
If this feature is something that is not within the requirements of hs_err printing. Maybe it could be enabled with some diagnostic flag, as a development/debugging tool for those specific scenarios when crashes have the behaviour of making print location unstable.
But I have for to little experience and knowledge about the requirements of VMError::report so I will leave the discussion to more veteran people.
I do however think it would be a nice feature to have for the times where it actually matters.
-------------
PR: https://git.openjdk.org/jdk/pull/11017
More information about the hotspot-dev
mailing list