Register output in assert case useful?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Register output in assert case useful?

Thomas Stüfe-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Register output in assert case useful?

dean.long
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?

+1

dl

> Kind Regards, Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Register output in assert case useful?

Vladimir Kozlov
In reply to this post by Thomas Stüfe-2
Yes, please.

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?

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.

Vladimir

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
>
Reply | Threaded
Open this post in threaded view
|

Re: Register output in assert case useful?

Thomas Stüfe-2
Hi Vladimir,

On Thu, Oct 26, 2017 at 9:25 PM, Vladimir Kozlov <[hidden email]
> 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
>>
>>