RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Thomas Stüfe thomas.stuefe at gmail.com
Sat Nov 11 07:35:22 UTC 2017


Oh, you are right, I should have seen this. Knowing this, forget my worries
about stability. Sorry for the noise :)

..Thomas

On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer <chris.plummer at oracle.com>
wrote:

> It's already restricted to non-product builds, but I'll add a comment also.
>
> thanks,
>
> Chris
>
>
> On 11/10/17 1:27 PM, Thomas Stüfe wrote:
>
> Hi Chris,
>
> Thank you. Yes, a comment may make sense, and/or restricting this function
> to not product. Otherwise the change is fine and useful, I’ll use it
> probably before long.
>
> Thanks, Thomas
>
> On Fri 10. Nov 2017 at 21:55, Chris Plummer <chris.plummer at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> There's certainly no intent to leave in place any calls someone might add
>> to pns2(). It's meant as a temporary debugging aide only. So if it were to
>> fail for any reason, IMO that's no different than adding any other sort of
>> temporary debugging code that could possibly crash. You fix your mistake
>> and resume your debugging. If you want I can add comments that include such
>> a warning.
>>
>> thanks,
>>
>> Chris
>>
>>
>>
>> On 11/10/17 12:11 AM, Thomas Stüfe wrote:
>>
>> Hi Chris,
>>
>> looks fine as a debugging aid.
>>
>> But it occurred to me that it may be a bit dangerous to call this from
>> non-errorhandler settings. I recall seeing quite a few secondary crashes in
>> VMError::print_native_stack() in hs-err files over time. Especially for
>> native non-java threads. Usually this did not matter that much because
>> these crashes are handled by secondary error handling when printing the
>> hs-err file. But if we call it outside of error handling, we are on our own.
>>
>> So. IMHO, to use this functions as a debugging aid is fine, if one can
>> accept a slight risk of crashing the VM. If this is not acceptable, may we
>> need some more tests for this function?
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer <chris.plummer at oracle.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191049
>>>
>>> diff --git a/src/hotspot/share/utilities/debug.cpp
>>> b/src/hotspot/share/utilities/debug.cpp
>>> --- a/src/hotspot/share/utilities/debug.cpp
>>> +++ b/src/hotspot/share/utilities/debug.cpp
>>> @@ -631,6 +631,24 @@
>>>    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>>  }
>>>
>>> +//
>>> +// This version of pns() will not work when called from the debugger,
>>> but is
>>> +// useful when called from within hotspot code. The advantages over
>>> pns()
>>> +// are not having to pass in any arguments, and it will work on
>>> Windows/x64.
>>> +//
>>> +extern "C" void pns2() { // print native stack
>>> +  Command c("pns2");
>>> +  static char buf[O_BUFLEN];
>>> +  if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) {
>>> +    // We have printed the native stack in platform-specific code,
>>> +    // so nothing else to do in this case.
>>> +  } else {
>>> +    Thread* t = Thread::current_or_null();
>>> +    frame fr = os::current_frame();
>>> +    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>> +  }
>>> +}
>>> +
>>>  #endif // !PRODUCT
>>>
>>> There is also a pre-existing thread with some discussion:
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/
>>> 2017-November/025134.html
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>>
>>
>>
>


More information about the hotspot-dev mailing list