On Fri, 28 Jan 2022 09:58:26 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> > > Two general remarks. One concern I have is that the new functionality > > > should be super stable, since nothing is more annoying than to crash > > > during stack dumping in hs-err file; I much rather have a call stack > > > without bells and whistles than an abridged one. Maybe we could, in > > > hs-err printing, if we got secondary crashes during callstack dumping, > > > repeat the step with all optional features (also name demangling) > > > disabled? This could also be done in a separate RFE. We'll know when this > > > happens, we can react then. > > > > > > I absolutely agree - stability should be the primary concern. An incomplete > > hs-err file should be avoided at any cost. Doing an additional "catch and > > repeat without optional features" sounds interesting to get more safety. > > Would such a thing be easy to add? Yes, it might be better to do that in a > > separate RFE. > > It is probably easy, but I also thing this would be better in a separate RFE. > And we already have a timeout per reporting step since JDK-8166944, so that > long-running steps don't spoil error reporting for everyone. We can just add > a second call stack print step if the first one failed. That sounds great. And good to know about JDK-8166944! > > The parsing of a single pc takes a little less than 0.01s. Of course, this > > is not a great way to measure performance. It also highly depends on the > > source files themselves, the machine setup etc. Thus, this cannot be > > considered a valid performance test. But still, I think these numbers can > > give us some indication of the order of magnitude. Compared to the current > > `ErrorLogTimeout` default value of 2min this looks promising. > > Okay, this looks reasonable. In our case, I remember having a very slow file > system and an overloaded machine. But this would be solved also by just > repeating call stack printing if the first attempt times out. Yes, I think so, too. Ah, I see, yes that would be an option in this case. > Cheers, and thanks for this patch! You're welcome! I'm glad this can help with the analysis of crashes in the future :-) Cheers, Christian ------------- PR: https://git.openjdk.java.net/jdk/pull/7126
