RFR(xs): 8147510: [windows] no text locations shown for register info in hs-err file

Thomas Stüfe thomas.stuefe at gmail.com
Thu Jan 28 13:01:16 UTC 2016


Hi Ioi,

thanks a lot for the review!

You are right, displaying the function name is more useful. I wanted to
postpone this until I could start
https://bugs.openjdk.java.net/browse/JDK-8147512, but now I took your
suggestion and implemented this anyway.

See here new webrev:

http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev

Notes:
-I decided to cut off the path for libraries to make the printout easier to
the eye; also, in the DLL-section we print out all DLLs including paths.
-There is no clean way to handle truncation of long library paths, so I
decided to at least detect truncation and if it happens to not print the
library at all. I want to avoid large on-stack buffers, therefore I keep
the result buffer relativly small (256 bytes). A better approach would be
to - if os::find is used from error handling - hand down the error handling
scratch buffer like we do in many other cases. But this is beyond the scope
for this small fix.

New printout looks like this:

 35 Register to memory mapping:
 36
 37 RIP=0x000000006ddd6a43 jvm.dll::crash_with_segfault + 0x13
 38 RAX=0xabc0000000000abc is an unknown value

Kind Regards, Thomas



On Thu, Jan 28, 2016 at 7:42 AM, Ioi Lam <ioi.lam at oracle.com> wrote:

> Hi Thomas,
>
> 5269 bool os::find(address addr, outputStream* st) {
> 5270   int offset = -1;
> 5271   char buf[255];
> 5272   if (os::dll_address_to_library_name(addr, buf, sizeof(buf),
> &offset)) {
> 5273     st->print_cr("%s + %x", buf, offset);
> 5274     return true;
> 5275   }
> 5276   return false;
> 5277 }
>
>
> Have you tried calling os::dll_address_to_function_name as well so you can
> get the function name?
>
> I noticed that the Linux version of os::find contains code for printing
> out the function name, but couldn't find an hs_err file where that code is
> actually used:
>
> bool os::find(address addr, outputStream* st) {
>     ...
>     if (dlinfo.dli_fname != NULL) {
>       st->print(" in %s", dlinfo.dli_fname);
>     }
>
>
> Thanks
> - Ioi
>
>
> On 1/19/16 11:53 PM, Thomas Stüfe wrote:
>
>> May I please have a review and a sponsor?
>>
>> Thank you!
>>
>> On Sat, Jan 16, 2016 at 10:42 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> could I please have reviews and a sponsor for this small fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>>
>>> When we print register to memory info in hs-err file, text addresses are
>>> not resolved on windows like on other platforms:
>>>
>>> "RCX=0x000000005efa0000 is an unknown value"
>>>
>>> This fix changes this (the same way it is implemented on other
>>> platforms):
>>>
>>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
>>> 0"
>>>
>>> Please note that this printout and the code behind it could be improved
>>> and cleaned up a lot. For instance, I know that using an on-stack buffer
>>> in
>>> os::find() is not the best implementation here. But I wanted a minimal
>>> change. For the follow-up work, I opened a new bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>>
>>> Thanks & Regards, Thomas
>>>
>>>
>>>
>>>
>>>
>


More information about the hotspot-runtime-dev mailing list