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

Yumin Qi yumin.qi at oracle.com
Mon Sep 8 20:35:37 UTC 2014


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