Register output in assert case useful?

Thomas Stüfe thomas.stuefe at gmail.com
Fri Oct 27 06:27:32 UTC 2017


Hi Vladimir,

On Thu, Oct 26, 2017 at 9:25 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> Yes, please.
>
>
Nice, I'll do this then. One change less to maintain downstream.


> We try to print values for failed asserts but not in all places. To have
> values in registers would be good. Do you also dump "Instructions:" near
> assert code?
>
>
Yes. We go into the error handler with a valid ucontext, so now all
reporting steps depending on a valid uncontext. The only thing missing is
the signal info, because there was no crash signal.


> One thing to watch out is when debugging code (in debugger) there is
> ability to continue execution when assert is triggered:
>
> http://hg.openjdk.java.net/jdk10/hs/file/068d316e905e/src/
> hotspot/share/utilities/debug.cpp#l209
>
> This should be preserved.


It is. We go the same code paths to process the assert, we only take a
short break before to store the ucontext.


>
>
> Vladimir
>
>
Cheers, Thomas


> On 10/26/17 6:37 AM, Thomas Stüfe wrote:
>
>> Hi all,
>>
>> when an assert happens, one does not have an ucontext_t and hence no
>> register context - that is why hs-err files generated by an assert do not
>> contain registers.
>>
>> But sometimes there are cases where it would be useful to know the content
>> of registers at assert - e.g. to know the current stack depth, or because
>> remnants in registers may help with investigating.
>>
>> At SAP we added a small feature to retrieve the current context when an
>> assert happens and make that part of the hs-err file. Works similar to the
>> SafeFetch logic: when an assert happens, we trigger a segfault and in the
>> signal handler we squirrel the ucontext away, before continuing with error
>> reporting. We do this right after the assert condition was evaluated, so
>> this is as close to the assert point as possible (basically, just a read
>> access which is part of the assert macro).
>>
>> I wonder whether there is interest in us contributing this?
>>
>> Kind Regards, Thomas
>>
>>


More information about the hotspot-runtime-dev mailing list