RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v2]

[Christian Hagedorn]

On Fri, 28 Jan 2022 09:58:26 GMT, Thomas Stuefe <stuefe at 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