RFR(XS): 8056930: Output host info under some condition for core dump

David Holmes david.holmes at oracle.com
Mon Sep 8 23:41:10 UTC 2014


Hi Yumin,

I'd overlooked the local buffer issue. Even a 1K buffer may be an issue 
if the crash we are trying to report about related to stackoverflow.

David

On 9/09/2014 6:35 AM, Yumin Qi wrote:
> Thanks for review again.
>
> Yumin
> On 9/8/2014 12:19 PM, Calvin Cheung wrote:
>> On 9/8/2014 11:43 AM, Yumin Qi wrote:
>>> Calvin,
>>>
>>>   Thanks for the review, yes, it is webrev01 (now updated with buffer
>>> len to 1024, see below).
>>>
>>> /lpBuffer/[out]
>>>
>>>     A pointer to a buffer that receives the computer name or the
>>>     cluster virtual server name.
>>>
>>>     The length of the name may be greater than
>>>     MAX_COMPUTERNAME_LENGTH characters because DNS allows longer
>>>     names. To ensure that this buffer is large enough, set this
>>>     parameter to*NULL*and use the required buffer size returned in
>>>     the/lpnSize/parameter.
>>>
>>> /lpnSize/[in, out]
>>>
>>>     On input, specifies the size of the buffer, in*TCHARs*. On
>>>     output, receives the number of*TCHARs*copied to the destination
>>>     buffer, not including the terminating*null*character.
>>>
>>>     If the buffer is too small, the function fails and*GetLastError*
>>>
>>> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx>returns
>>>
>>>     ERROR_MORE_DATA. This parameter receives the size of the buffer
>>>     required, including the terminating*null*character.
>>>
>>>     If/lpBuffer/is*NULL*, this parameter must be zero.
>>>
>>> In winbase.h:
>>>
>>> #ifndef _MAC
>>> #define MAX_COMPUTERNAME_LENGTH 15
>>> #else
>>> #define MAX_COMPUTERNAME_LENGTH 31
>>> #endif
>>>
>>> So it is 15 in most case, but it is not enough for most cases in
>>> network name, I put 4K here think that is enough for most of the cases.
>> The length of 15 is for the NetBios name. In this case, we want to get
>> the DNS host name. That's why 15 won't be sufficient.
>>
>>> According to the description, I set buffer = NULL, and size to 0, the
>>> call failed.
>> Yes, the call should fail with the return code of ERROR_MORE_DATA and
>> the third parameter ( _Inout_  LPDWORD lpnSize) will contain the
>> number of bytes required to receive the name. This way, the caller can
>> dynamically allocate a buffer large enough for the name.
>>>
>>> I updated again, and set the buffer len as 1K, 1024 bytes, which I
>>> think should be enough.
>> Yes, I think it's large enough for this fix.
>>
>> Calvin
>>> The specs in MSDN are confusing some time and not consistent in their
>>> pages.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>>
>>>
>>> On 9/8/2014 10:29 AM, Calvin Cheung wrote:
>>>> Yumin,
>>>>
>>>> os_windows.cpp
>>>>
>>>> 1592   char buffer[4096];
>>>>
>>>> Why do you need a 4k buffer?
>>>>
>>>> According to:
>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724220(v=vs.85).aspx
>>>>
>>>> "Each name can be up to 255 bytes total. "
>>>>
>>>> So maybe 256 is sufficient?
>>>>
>>>> btw, is your new webrev located at:
>>>> http://cr.openjdk.java.net/~minqi/8056930/webrev01/ ?
>>>>
>>>> thanks,
>>>> Calvin
>>>>
>>>> On 9/8/2014 10:17 AM, Yumin Qi wrote:
>>>>> Hi,
>>>>>
>>>>>   I made a small change to Windows part, when GetComputerNameEx
>>>>> fails, instead of do nothing, output "N/A".
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>> On 9/5/2014 2:46 PM, Yumin Qi wrote:
>>>>>> Please review
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056930
>>>>>> Webrev: http://cr.openjdk.java.net/~minqi/8056930/webrev00
>>>>>>
>>>>>>   After java crashed, we would like to know the host on which it
>>>>>> failed especially when doing parallel testing on multiple
>>>>>> machines. The most useful for knowing host name is telling if the
>>>>>> test is hardware related, that the test can only repeat on it.
>>>>>> This piece of code help to print out host name in debug mode.
>>>>>>
>>>>>>   Test: manually tested on Unix/Linux/Windows with
>>>>>> -XX:+CrashGCForDumpingJavaThread.
>>>>>>    JPRT
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>
>>>>
>>>
>>
>


More information about the hotspot-runtime-dev mailing list