RFR: JDK-8296907: VMError: add optional callstacks, siginfo for secondary errors [v11]
Thomas Stuefe
stuefe at openjdk.org
Thu Dec 1 16:26:12 UTC 2022
On Thu, 1 Dec 2022 15:59:48 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Revert accidental change
>
> src/hotspot/share/utilities/vmError.cpp line 1507:
>
>> 1505: // Any information (signal, context, siginfo etc) printed here should use the function
>> 1506: // arguments, not the information stored in *this, since those describe the primary crash.
>> 1507: static char tmp[256]; // cannot use global scratch buffer
>
> This is not thread safe. You could have parallel threads which trigger a secondary crash. Not sure if it will be a problem in practice, since it is rather rare. I would still use a local buffer, since 256 bytes is small.
I'm not sure how this would happen: we only end up here if we are the original thread that triggered the first fault (_first_error_tid == me). Otherwise, we would end up in `os::infinite_sleep()` at lines 1455ff. If a different thread crashes inside signal handling, between signal handler start and infinite_sleep, it will just keep crashing endlessly and run out of stack.
> src/hotspot/share/utilities/vmError.cpp line 1527:
>
>> 1525: {
>> 1526: if (ErrorLogSecondaryErrorDetails) {
>> 1527: static bool recursed = false;
>
> Same as above. Would not work if we have parallel crashes, but I don't think it warrants making the code more complicated to catch this.
See my answer above. My assumption here is we are singlethreaded, because all but the first thread end up sleeping.
-------------
PR: https://git.openjdk.org/jdk/pull/11118
More information about the hotspot-dev
mailing list