[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: Register output in assert case useful?
From:       Thomas_Stüfe <thomas.stuefe () gmail ! com>
Date:       2017-10-27 6:27:32
Message-ID: CAA-vtUzH+-jrMo0ju_M+XvjEUB9yrT1r_=qvDBeTTh255b=+qQ () mail ! gmail ! com
[Download RAW message or body]

Hi Vladimir,

On Thu, Oct 26, 2017 at 9:25 PM, Vladimir Kozlov <vladimir.kozlov@oracle.co=
m
> 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=C3=BCfe 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 no=
t
>> contain registers.
>>
>> But sometimes there are cases where it would be useful to know the conte=
nt
>> of registers at assert - e.g. to know the current stack depth, or becaus=
e
>> 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 t=
he
>> SafeFetch logic: when an assert happens, we trigger a segfault and in th=
e
>> signal handler we squirrel the ucontext away, before continuing with err=
or
>> 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
>>
>>
[prev in list] [next in list] [prev in thread] [next in thread]